Then the definition should be even wider: there are many situations when there is only potential for user-visible bad behavior. The classic situation when a bug is masked by another bug. The fact that the first bug is not exposed (yet) is not a reason to not call it a bug.
Also, there are internal bugs - leading to faulty intra-cluster behavior which may be mitigated by some cluster's redundancy mechanisms. Like a bug in the ZK configuration which leads to frequent reconnects, which doesn't, however, lead to anything visible by a Druid user nor operator (note: the situation is made up). This could have been called "improvement" unless it was caused by a programming mistake. I would not call anything which is caused by a programming mistake a mere "improvement", it's always a "bug" for me. On Thu, 15 Aug 2019 at 08:08, Gian Merlino <g...@apache.org> wrote: > I think it'd be ok to call those examples bugs. In professional programming > contexts I've always used 'bug' in a wide sense, meaning any sort of flaw > or issue in a system that causes user-visible bad behavior. It could be a > programming mistake, a design flaw, or even a problem with a dependency. > (Conversely, if there's no user-visible bad behavior, I wouldn't call it a > bug; maybe it'd be an improvement.) > > On Tue, Aug 13, 2019 at 6:51 AM Roman Leventov <leven...@apache.org> > wrote: > > > There have been many times, and several in the last few days ( > > https://github.com/apache/incubator-druid/issues/8291, > > https://github.com/apache/incubator-druid/issues/8263) when I wanted to > > label an issue as 'bug' but the semantics of the word "bug" don't really > > apply. For me, "bug" means "somebody made a programming mistake at some > > point". This doesn't apply to the issues linked above. I would say about > > them "the system, as it is currently implemented, fails (or may fail) > under > > certain circumstances and shall be improved". PRs which would fix these > > issues shall be labelled 'Improvement'. > > > > I think renaming 'bug' into 'defect' would be useful to broaden the > > applicability of the label. > > >
