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 <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~papercuts-ninja Post to : [email protected] Unsubscribe : https://launchpad.net/~papercuts-ninja More help : https://help.launchpad.net/ListHelp
