Bugzilla

[Colin Scott]

(I've already replied to this message once, but forgot to copy to the group.  This is now a slightly extended and amplified version of that original reply - and it is now also properly addressed!)

> might* be either bugs and design defects
> and deficiencies that might be either problems causes by various 
> outside forces (such as user error) 

I have no doubt that a proportion of them will be just that.  But I also have no doubt that a larger proportion will not.

> As a developer myself (of other software) I sometimes get bug 
> reports from users who experience problems not because of actual
> software bugs, but due to things like people failing to read
> documentation or doing various things 'wrong' on some level. Sometimes
> it is a documentation error or because someone wants to do something
> the software is not meant to do.

I know what you mean, but such reports are still worthy of attention, especially where they are not isolated.  If the software is Working As Designed (WAD), yet you still get multiple reports of bugs within it, it is quite possible (though certainly not a foregone conclusion!) that the users are right and it is the design that is wrong.   Sometimes it is a matter of things not being done in what seems like an intuitive manner to many/most users (though that does not make it "wrong", it may still not be "right", if you see what I mean!).  Sometimes it is because of inconsistencies in either design or visible method.  I can't offhand think of too many examples, but perhaps the most obvious one is the re-sizing of columns in the Register.  It *is* possible to re-size the columns in the register, but it isn't intuitive - and the number of questions asked about it in this forum demonstrate that whilst it works it isn't "right".  I am sure we can all think of other examples.  In m!
 y view, 
whilst the program in this context is WAD, this bit of the design is flawed and should be re-visited.   (I wouldn't put it at a high priority, but I would have it on the list of things to do.)

Similarly, there are several things that people want to do that do not necessarily fit with how gnucash is currently designed/implemented.  That doesn't make the users wrong!  

> or something else or are (more likely) not ones that affect the 
> developers 

I appreciate that the developers will inevitably view as a higher priority those items that affect themselves, but it would be most unwise of them to ignore the rest.  To do so would render the entire bug-reporting and user-feedback process something of a sham!

> or (see above!) not verified or reproducable by the developers.

In which case one would hope that the bug reports would be suitably annotated, and closed where appropriate.

Colin