[scribus-dev] Most Annoying Bugs
Sarath M S
sarath.ms at gmail.com
Thu May 29 12:22:04 UTC 2014
Craig Bradney <cbradney at scribus.info> wrote:
>On 29/05/2014 1:00 pm, JLuc wrote:
>> Scribus now is my only DTP tool.
>> I'm happy with it, but not totally because some bugs hinder my
>> 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
>> 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
>> 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
>> HardHacks, as also called them Libreoffice team, have a nice
>definition we could use to start with.
>> For the regular "MAB pages" they use now mostly, they have :
>> 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.
>scribus-dev mailing list
>scribus-dev at lists.scribus.net
This is a good idea. It will help developers prioritize important contributions whenever possible.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus-dev