[Scribus] Reporting bugs

[Maciej Hanski]

Louis Desjardins napisa?(a):
> Hi,
> 
> Here are a few thoughts I want to share about reporting bugs. This 
> relates to bug #3802 with which, by the way, I fully agree.
> 
> We have an increasing number of bug reports, many of which are 
> duplicates or simple enhancements to ideas already suggested.
> 

The bugtracker workflow proposals we've started to think of in the RFE
#3802:

http://bugs.scribus.net/view.php?id=3802

don't necessarily focus on descreasing the number of submitted reports
(although it could be a welcome side effect), but more on _increasing_
the bugtracker throughput and utilizing the know how of this mailing
list to effectively support the development. As a consequence, it should
bring some relieve to the Scribus team and spare them some of the time
they've been spending on reviewing/validating bug reports.

Enough theory, let's see some real life examples and how it could work:

== Case #1:

http://bugs.scribus.net/view.php?id=1393

An user reports some problems with printing scribus documents on his
system. Scribus devs try to reproduce it (much time), they can't, the
bug remains open forever  or will be closed as "unable to reproduce".

Possible solution:
-- the report will be added as an child relation to the "Printing
experts" group
-- all members of "Printing experts" group get a mail notification
-- they (and not the Scribus devs) try to reproduce it on their systems
-- as a result, they can either deliver an exact sequence of steps to
reproduce the error or recommend it for closing


== Case #2:

http://bugs.scribus.net/view.php?id=3707

An user reports some Copy&Paste errors on FreeBSD. Neither the devs nor
anybody of the current bug trackers run FreeBSD, and they cannot
reproduce it on Linux. A stalemate.

Possible solution:
-- new child relation in "Other operating systems" group
-- all members of this group, some of them FreeBSD users, get a notification
-- they try to confirm the bug on FreeBSD


== Case #3:

http://bugs.scribus.net/view.php?id=3803

An users reports, the pdf form fields cannot be changed and uploads his
.sla file (an ideal case). Verifying this report means opening the
uploaded file, playing with it a little bit, perhaps asking additional
questions. Some knowledge about PDF forms might be needed. Much time,
that could be spent on developing Scribus.

Possible solution:
-- a new relation in "PDF Form experts" group
-- mail notification
-- our experts either recognise it as lack of experience
-- or can confirm the error


There can be many more cases like the abovementioned, in particular for
RFEs, but the main message is, bug validating and shaping is very time
consuming, and we could try to shift a big part of this effort from the
developers to experienced users.

Opinions?

Maciej




	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de