[scribus-dev] Most Annoying Bugs

[Louis Desjardins]

2014-05-29 11:31 GMT-04:00 Andreas Vox <avox at arcor.de>:

>
> 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.
>

+1

>
> 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?
>

I'd suggest we continue using the bugtracker. We could add a tag to the
identified bugs so it’s easy to search only for those, or filter.

If these could be automagically linked to the website as to display in a
dedicated page only to make it more appealing and readily understable for
the people who don’t want to look at the bug tracker, it would be a nice
feature but not essential of course.

I like the word "wholeheartedly" and I support this idea!

Louis


> /Andreas
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20140529/e9d9b264/attachment.html>