3 ms·
Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implemen
by samhatoum 10y ago
Actually this is where you can be flexible with a specification. If the ticket was initially specified as embedding the fonts, then technically it's an implementation defect since it was already specified. However, as a team you might decide it's not too bad to download fonts instead of embedding them. This is where you can be flexible with the solution. Instead ob being rigid with expectation when the reality is the bug can comfortably be re-classified.
If however the loading time with downloading the fonts is something the team is not as per the team's quality standards and they are not willing to live with it, then it should absolutely remain as a bug.
Now that the classification portion is out of the way, the team priority is to work on bugs first no matter what.
So I'm saying that "the actual definition of what a bug is" should be stated as a guideline and the team can decide on an ongoing basis. Some guidelines might be rigid, others not so much.
- Dylan16807 10y agoYou can make whatever categories you want. But if your definition of "bug" is in disagreement with the rest of the world, don't tout it as having "zero bugs". Just pick a different word, one that doesn't mislead.
- samhatoum 10y agoI don't think the world has an agreed definition of a bug, or at least I've not seen it! I understand that the issue people have is with the wording of the zero-bug. As I've mentioned elsewhere it's still true that it is a striving towards zero-bug and I've seen it first hand where we get to 0 known bugs. I'll meditate on this a little and see what I come up with. I really do appreciate this feedback :)
- Dylan16807 10y agoDefinitions very somewhat, but I think very few people would say that the business impact of a problem changes whether it's a 'bug'.