Restrictions on development workflow

[mewid]

It would feel better if I came with solutions and ideas, rather than concerns. But I don't have the former at the moment so I'll just drop the latter here for now!

This application is very nice already, and promising. But the way the metrics are calculated might pose developers with the decision to either change their way of working (to get good metrics), or implement DORA metrics another way.

My top concerns for now:

• If I understand the gathering of Lead Time for Change correctly, I could mess upp the metrics by rebasing my branch.
• I am discouraged from merging a fix PR instead of reverting a failing PR, since no incident will be created

Keep up the good work!

[jayantbh]

Solid inputs @mewid. ❤️

1. You're right about the concerns about lead time. Rebasing might mess with the lead time metric. And we could definitely use ideas on how you'd think this can be handled better. ✨
2. Well, yes, totally the case. But only for now. We'll add support for more configuration on PRs to treat as incidents/hotfixes, integrations like PagerDuty, OpsGenie, etc. very soon! 🚀

[mewid]

1. The only thing I can think of is to communicate some kind of standard that the developer would have to abide to. To add the first commit timestamp or hash on PR creation as a comment of a certain format, or as something else that should be queryable by Middleware. Or to have an open api endpoint one could call on the creation of the first commit specifying the info needed, which would be stored and later correlated with the PR on merge. Not an optimal solution, I'll continue to think about it.

2. That's great!