[scribus-dev] Most Annoying Bugs

JLuc jluc at no-log.org
Thu May 29 11:00:20 UTC 2014


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




More information about the scribus-dev mailing list