Bugzilla

[Colin Scott]

> other bugs may be fixed first for a plethora of reasons.

Indeed, and I don't have any problem with that in principle.  However, the sheer number of fairly serious problems with crucial bits of functionality is a tad worrying.

> * Certain bugs are more visible to the devs than other. When a dev 
> hits a certain bug every day during his typical workflow, he's 
> probably more inclined to fix that bug first.

BTDTGTTS!  But whilst it is entirely understandable, the visibility to the *user* should prevail.

> * GnuCash is a large project. Each dev typically knows some parts 
> of it very well and others hardly at all. If a critical bug is in 
> an area that has currently no active developers, that bug will 
> probably stay open because it would take a huge effort for another 
> dev to figure out how it works. It's not impossible, but it's a 
> matter of trade-off of available time.

Again, that is fully understood in principle.  What is harder for the user to understand (especially a user without experience of the software development and support) is the number of bugs - many of them longstanding and/or serous - still in Bugzilla where there is 

*  no indication that the Team have even see the report,  or

*  no indication of the significance the team assigns to the bug, or

*  no indication of what, if any, action is proposed, or

*  no indication of any kind of timeline for implementing and releasing a fix

Of course, it is always frustrating when things one needs don't work properly, and the bug isn't fixed *yesterday* - but these are facts of life.  The lack of information, on the other hand, is much harder to cope with.

> it's important to realize GnuCash is not a project 
> backed by a big company that has support people and devs to 
> allocate at will.

Indeed.  And for that reason I do try to keep my impatience in check, although I am aware that I am not always successful.  My problem, and apols if it sometimes comes through a little too strongly!

> On the other hand, I heard your initial remark on the number of 
> unconfirmed bugs and I believe it would be good if I had some more 
> discipline there. So I intend to walk through those in my work 
> areas (being mostly business features and GUI) in the near future 
> and see which ones I can confirm at least.

Thank you - I appreciate that this will be a signficant effort, but I think it could be helpful for all concerned.

> I don't put timings on 
> the bugs because I don't know how much free time I'll have 
> available to work on bugs and I don't know the free time of the 
> other devs either.

Again, fully understood.   However, were there some measure of the amount of work required, and the priority assigned, then one might perhaps form some sort of picture of both  the total queue, and a given bug's position within it.  Possibly such a tool might even help you in your own planning and scheduling ...  :-)

Colin