papercuts-ninja team mailing list archive

[<druellan@xxxxxxxxxxxxxx>]

I tend to agree with Vish: a new feature can have all the requisites to
become a valid papercut, perhaps less frequent than a bug, but can happen,
and I think it's not fair disregard it just because developers use a
semantic differentiation; and that's also a problem with valid papercuts,
that turn to be new features during the triage process.

But I can see a point from the implementation standpoint. Is not as
straightforward as fixing a bug: you need approval from the development
team, perhaps some UI guidance, translations, etc. 

But we can find some common ground to handle it: for example, we maintain
new features as a valid papercuts, but outside the Papercuts Ninja scope,
trying to coordinate their implementation with the actual developer.

On Fri, 14 Dec 2012 13:54:02 -0500, Vish <vish@xxxxxxxxxx> wrote:
> On 12/14/2012 09:43 AM, Chris Wilson wrote:
>> Hey,
>>
>> I've been thinking a lot lately (through my job) about adding options 
>> to software. Personally, I try to avoid it, both at work and in my 
>> personal projects, as feel they get in the way of the user being able 
>> to understand how your app works, as well as adding more routes 
>> through the code that need to be maintained.
>>
>> There's a great article here 
>> <http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html> on 
>> the subject.
>>
>> This <https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/264816> 
>> bug report got me thinking about how this applies to paper cuts. 
>> Adding an option to an app may sound like an easy fix that satisfies 
>> the largest number of people, but is it really going to satisfy more 
>> people then the app would if it weren't added? Wouldn't it be a better 
>> solution to design a work flow that didn't require an added option? Is 
>> there really a demand for these options?
>>
>> My question to you is: should requests to add options to app be 
>> considered paper cuts? Personally I think they shouldn't, and we 
>> should instead look at the underlying problem that got the person 
>> asking for the option in the first place. I think we should also 
>> remember that the paper cuts project exists to fix the issues 
>> affecting the *majority of average users, *and a lot of options that 
>> are requested will only be of any real interest to a minority of 
>> users, not to mention the fact that average users don't usually 
>> customise their computer in the first place.
>>
>> What are people's thoughts in this?
>>
>> Chris
>>
>>
> Hi Chris,
> Traditionally, requests to add new options/checkboxes were usually not 
> papercuts. You got to think of them in terms of new feature requests.
> But it is not just dismissing such bugs as 'not a papercut'. Sometimes, 
> we have to think of the use-case for such an issue. The reporter might 
> have a valid use-case, which affects a majority, that we have previously

> not thought about. Maybe the solution, that the reporter is proposing, 
> would be better if it was the default behaviour.
> So, for papercuts we got to think of in terms of tweaking/changing the 
> default behaviour rather than adding a new option. If it is a minor 
> tweak that could help improve the desktop experience for everyone, then 
> we should look into pushing for that change as a papercut.
> 
> Cheers,
> Vish