<div dir="ltr"><div class="gmail_extra">2014-05-29 11:31 GMT-04:00 Andreas Vox <span dir="ltr"><<a href="mailto:avox@arcor.de" target="_blank">avox@arcor.de</a>></span>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Am 29.05.2014 um 13:00 schrieb JLuc:<br>
<div><div class="h5"><br>
> Hello,<br>
><br>
> Scribus now is my only DTP tool.<br>
> I'm happy with it, but not totally because some bugs hinder my everyday use.<br>
> I can circumvent them, but it's like riding on a bike<br>
> with one hand deep into my trouser's pocket : uncomfortable.<br>
><br>
> Most of these hindrances are longlasting bugs (many years !).<br>
> Beside, quite strange is that some of them aren't even acknowledged on the bug tracker.<br>
> I will not here talk of these bugs that hinder my everyday use,<br>
> because - who knows - they might be specific to my uses,<br>
> and IMO, most important would be to define :<br>
> which are the Most Annoying Bugs that are painfull,<br>
> the most of the time, for the most of the users.<br>
> - this is very different from the 1.5 roadmap<br>
> which mainly includes new features to be coded,<br>
> or very recent features to be improved -.<br>
><br>
> This list would bring attention toward these bugs.<br>
> It would help motivate some of the devs someday to tackle one of them.<br>
> Beside, as an occasional dev, i feel that it could help external devs<br>
> to work on one of them, since prior discussions and consensus<br>
> might provide technical hints on the scribus strategy and current works,<br>
> and faith  that a provided patch has a chance of ever be merged.<br>
><br>
> If some of you agree on this MAB idea,<br>
> if some of the core devs agree on this idea,<br>
> then we should first agree on a list of criteria<br>
> that define a bug as Most Annoying Bug.<br>
> For reference we could look at how LibreOffice deals with the subjects.<br>
> HardHacks, as also called them Libreoffice team, have a nice definition we could use to start with.<br>
> <a href="https://wiki.documentfoundation.org/HardHacks" target="_blank">https://wiki.documentfoundation.org/HardHacks</a><br>
> For the regular "MAB pages" they use now mostly, they have :<br>
> <a href="https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs" target="_blank">https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs</a><br>
> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=44446" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=44446</a><br>
> Quote of the first liste page : What is a hard hack ?<br>
> Hard hacks should meet the below requirements:<br>
> - Be relatively annoying for a significant amount of people<br>
> - Be relatively difficult to solve and/or track down<br>
> - Crashes/data loss are good candidates but not necessary<br>
> - Backtraces should be done on proposed hard hacks before they become accepted hard hacks<br>
> - Enhancement requests should NOT be on the list<br>
><br>
> What do you think of that ?<br>
><br>
> JLuc<br>
<br>
</div></div>We had a similar idea before (Top 10 Scribus issues) but it was never realized. I wholeheartedly support this idea.<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I don't think we need special requirements for the list except for the first one.<br>
UI quirks and missing functionality should be as legitimate as crashes and bugs. The first two would just need a clear<br>
description of how a solution would work from a user perspective.<br>
<br>
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?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>I like the word "wholeheartedly" and I support this idea!</div><div><br></div><div>Louis</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
/Andreas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
scribus-dev mailing list<br>
<a href="mailto:scribus-dev@lists.scribus.net">scribus-dev@lists.scribus.net</a><br>
<a href="http://lists.scribus.net/mailman/listinfo/scribus-dev" target="_blank">http://lists.scribus.net/mailman/listinfo/scribus-dev</a><br>
</div></div></blockquote></div><br></div></div>