[scribus-dev] Most Annoying Bugs

[Andreas Vox]

Am 29.05.2014 um 13:00 schrieb JLuc:

> Hello,
> 
> Scribus now is my only DTP tool.
> I'm happy with it, but not totally because some bugs hinder my everyday use.
> I can circumvent them, but it's like riding on a bike
> with one hand deep into my trouser's pocket : uncomfortable.
> 
> Most of these hindrances are longlasting bugs (many years !).
> Beside, quite strange is that some of them aren't even acknowledged on the bug tracker.
> I will not here talk of these bugs that hinder my everyday use,
> because - who knows - they might be specific to my uses,
> and IMO, most important would be to define :
> which are the Most Annoying Bugs that are painfull,
> the most of the time, for the most of the users.
> - this is very different from the 1.5 roadmap
> which mainly includes new features to be coded,
> or very recent features to be improved -.
> 
> This list would bring attention toward these bugs.
> It would help motivate some of the devs someday to tackle one of them.
> Beside, as an occasional dev, i feel that it could help external devs
> to work on one of them, since prior discussions and consensus
> might provide technical hints on the scribus strategy and current works,
> and faith  that a provided patch has a chance of ever be merged.
> 
> If some of you agree on this MAB idea,
> if some of the core devs agree on this idea,
> then we should first agree on a list of criteria
> that define a bug as Most Annoying Bug.
> For reference we could look at how LibreOffice deals with the subjects.
> HardHacks, as also called them Libreoffice team, have a nice definition we could use to start with.
> https://wiki.documentfoundation.org/HardHacks
> For the regular "MAB pages" they use now mostly, they have :
> https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs
> https://bugs.freedesktop.org/show_bug.cgi?id=44446
> Quote of the first liste page : What is a hard hack ?
> Hard hacks should meet the below requirements:
> - Be relatively annoying for a significant amount of people
> - Be relatively difficult to solve and/or track down
> - Crashes/data loss are good candidates but not necessary
> - Backtraces should be done on proposed hard hacks before they become accepted hard hacks
> - Enhancement requests should NOT be on the list
> 
> What do you think of that ?
> 
> JLuc 

We had a similar idea before (Top 10 Scribus issues) but it was never realized. I wholeheartedly support this idea.

I don't think we need special requirements for the list except for the first one. 
UI quirks and missing functionality should be as legitimate as crashes and bugs. The first two would just need a clear
description of how a solution would work from a user perspective.

Any ideas on how you would manage such a list? Should we do it with our bug tracker or do you think of an extra webpage?

/Andreas