[scribus-dev] Most Annoying Bugs

[Craig Bradney]

On 29/05/2014 1:00 pm, JLuc wrote:
> 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 ?
> 

Yes, good idea.

A wiki page needs creating with a list of the bug and the description.

Craig