brejoc / filtra Goto Github PK

Right now this is hard-coded to bugs and l3. This should move to the config

We have the notion of priorities. This goes from P1 (most severe) down to P3. Right now more levels are at least not present in GitHub issues.

In addition to having "bugs" and "l3" bugs, it would be nice to also have the amount of bugs in each severity level. This should also be broken down by board.

• P1 to P3 bug count in total
• P1 to P3 bug count per board

• What is filtra?
• Install instructions.
• Config parameter.
• Screenshots.
• New TOML config.

https://github.com/brejoc/filtra/blob/master/config.toml#L8-L9

It would make sense, if those definitions would be lists. This way users could have multiple columns falling into the same category.

Add metric with last data collection timestamp so that we can tell when data was collected from Github.

"last collection" (timestamp)

Right now Filtra is only able to collect metrics from one board. In order to change that we'd have to do the following changes:

• Change configuration, so that multiple boards can be configured.
• Change calculation for multiple boards. (This is blocked by this: #20)
• Introduce lables to differentiate metrics for boards.

Follow up of #28.

Right now there is no PostgreSQL container created and used in the docker-compose file.

This might be a good candidate to replace the long running go routine.

@paususe I could use your input here. Right now the lead time is calculated like this:
creation time of the issue - closing time of the issue.

An other way of viewing this would be the addition to a specific board. While working on the cycle time I noticed that we can separate events by board name and so we could also view the lead time as team specific. Every team has their own board, that's why that could make sense.

But of course we could also keep the lead time like it is (with the issue creation time) and introduce an other metic that reflects the addition to the team board.

What do you think?

Right now we only collect the amount of blocked issues in total. It would also be good to know how many of those issues are actually bugs. Bugs should be identifiable via the config viable bugLabels.

gh_cycle_time, gh_lead_time, gh_open_bug_issues, gh_open_l3_issues and `gh_planned_issues´ are different compared to the master branch. There has to be something wrong.

See: https://github.com/brejoc/filtra/tree/master-multi-boards

… aka events. We are only fetching 250 of them.

See: shurcooL/githubv4#43

This is not that hard. The implementation would be pretty much identical to this and more information on how to get the syscalls can be found here.

It would be nice if the project would provide a docker-compose file that sets up the stack needed to run this.

The Prometheus exporter shouldn't just fail when an error happens. Instead it could just continue serving the metrics, log the incident and wait for the next update interval, or maybe even schedule a shorter interval. Hitting the rate limit would be such a case for example.

Types and content are not checked.

With issue #14 out of the way, we can think about having a lock for updateLoop(), so that it won't run twice of the interval is short enough to overlap with the time it takes to fetch the metrics.

It's only possible to fetch 100 results from the Github API at once.

Right now we can only see how many open and closed issues are there in total. But this could also be broken down by board.

Right now all of the closed issues are used to calculate lead and cycle time, but bugs should be excluded.

Maybe it would even make sense to have lead and cycle times for bugs.

If an issue was added to multiple boards, this might taint the results. What can we do here?

Add test scenario, to test and detect e.g. those cases: #20

This is somewhat related to the separation of bugs, since they also have to be identified via label.

Right now only basic metrics are provided.

• Calculate lead time
• Calculate cycle time