[Tracker]Implement a "Zero bug" policy

[VannTen]

This has come up during the Spring retrospective and we could benefit from formalizing what it means to decide if we want it, and how.

The following is my opinion, which does not have the weight of experience (on that subject).

---

TL;DR: If we can live with it, it's not a bug, it's an improvement (I stole that one)

Alternative TL;DR: It's not about being bug free, but about being known bug free.

At the start of the sprint, the product owner review all confirmed (aka reproducible) bugs and decide for each if it's need to be fixed in the sprint:

• if it does, it's prioritized above all else
• if it does not, we don't consider it a bug:
  • either we won't fix it
  • or it will still be good to work on, it's a (potential) improvement

The criteria should be a quantified impact on something we care about (customers/users ? Crash failures ? etc).

I think the important part is to consider that a bug is something which we should imperatively fix in a defined period of time (a sprint looks like a good one).

The supposed benefits:

• easier issues prioritization. Bugs are removed from arbitration and always comes first
• less workarounds. Ideally we should never need to work around bugs, because if we do, we should be working on fixing the bug instead.
• less "rethinking" of bugs: "Is this still valid/happening ?"

This relies heavily on a good triaging process for bugs. Especially, I think a bug which does not have a clear reproducer should not be triage/accepted (reproducing is part of the triage). This might sometimes be difficult though.

The criteria used for judging the bugs is also a question mark for me right now (I don't think "customers are loosing money" apply to Thoth yet ?).

Three blog posts which I found insightful on the subject (with various takes):

• https://www.xolv.io/blog/articles/zero-bug-software-development/
• https://zoopla.blog/posts/2022/zero-bug-policy/
• https://medium.com/next-level-german-engineering/zero-bug-policy-experience-3121b3046326
• https://www.infoq.com/news/2021/11/zero-bug-policy/

@cgoern

/triage accepted

[goern]

/sig user-experience /kind documentation /priority critical-urgent

[goern]

@VannTen could you formulate this in a few guiding principles? what are the rules for our 0bug policy? maybe its just a verbalized https://zoopla.blog/img/99c54607-768.avif ?

[VannTen]

Yeah I think that image is spot on.

Should I make an operable principles list:

1. We try hard to confirm/triage bugs regularly, in particular before sprint planning. (related to "assign to sigs" discussion lately)
2. At the start of sprint, the Product Owner (I guess you @goern ?), establish the true bugs (-> having an impact)
3. True bugs are planned first in sprint planning, other are closed or re-qualified as improvements.
4. Rest of the backlog is planned as usual

Things we need to define:

• what's the critera for bug/not-bug / the "impact threshold"

---

As a side note, https://github.com/thoth-station/thoth-application/issues/810 feels relevant to this. (kind/documentation struck me as quite odd (we can have a documentation bug or feature or improvement) and there is some other stuff)