Re: [xwiki-users] Paper Cut draft

Hi Vincent, Paper Cuts should be maintained by users (approving, voting) like me, not by you.

For you it would be important (more effort) only by release planning: - reviewing the most voted paper cuts and including some of those in the future release

I think, at the moment you do the same work, but without to know which (small) usability issues are more annoying. You will get just more feedback, but I'm not sure, if you will really happy with it, won't you?

These ideas are just different things: - I suggest to run a project for improving of usability (primarily it's good for users)

- you idea is to differ the difficulty of issues (primarily it's good for (new) developers) Not all easy/trivial issues are paper cuts from users point of view. And there may be small usability issues, that can be fixed only very hardly.

I would like to contribute to the usability project, but without yours and other xwiki commiters agreement it wouldn't make any sense...

The second approach is not really interesting for me, because it's not my intention to become an xwiki developer. But it's still very good idea.

Regards, Roman Am Samstag, den 03.10.2009, 13:05 +0200 schrieb Vincent Massol: > Hi Roman, > > Thanks for working on this. > > On Oct 3, 2009, at 12:23 PM, Roman Friesen wrote: > >> Hi Vincent, > >> please review the Paper Cut draft (beta): >> http://dev.xwiki.org/xwiki/bin/view/Drafts/PaperCut > > Ok I've read it. I agree with it except for the workflow you propose. > It's too complex and has no chance of being able to be maintained > IMO. > Even more it'll make it more difficult to maintain our current > difficulty field (which we already have a very hard time > maintaining - > check how many trivial issues don't have it set for ex). > > I'd like to suggest what I've already suggested, i.e to reuse the > existing "trivial" difficutly field instead and consider all trivial > issues as paper cuts. > >> If you agree, please create the field "Paper Cut" in JIRA projects >> with >> the following values: >> - reported >> - approved >> - rejected >> Default value: None > > This seems too procedural IMO and I still don't easy how using the > difficulty field won't work. > > WDYT? > > Thanks > -Vincent > >> Regards, >> Roman >> >> >> Am Sonntag, den 20.09.2009, 12:56 +0200 schrieb Roman Friesen: >>> The problem is to make a clear definition of paper cuts, so we >>> don't >>> have thousands of that, then it would be really a mess indeed. Sure >>> the >>> best would be just to fix all usability issues, but it's not a real >>> approach. >>> It is also important to define how these paper cuts should be >>> handled. >>> >>> I would suggest the following: >>> >>> 1) Intention >>> Fixing the worst usability issues that affects the most users - >>> Paper >>> Cuts. >>> Together with promoting of the paper cut project it should allow to >>> attract more xwiki users and contributors. >>> >>> 2) Definition (Scope) >>> A Paper Cut is: >>> - a _usability_ issue from the users point of view >>> - that the _average_ user would encounter during his/her _first_ >>> day of >>> using xwiki >>> - the presence of which makes the xwiki more difficult or less >>> pleasant >>> to use >>> - occurring within an _existing_ piece of software >>> (for the "difficult level" see below) >>> >>> 3) Process >>> - a user reports a usability issue that meets the definition above >>> and >>> marks it as a Paper Cut in jira (the field "paper cut": >>> reported/approved/rejected) >>> - paper cut maintainer (me? :D) checks reported paper cuts and sets >>> the >>> value to "approved" or "rejected" >>> - a xwiki developer sets the difficult level of the issue (but it >>> does >>> not matter for the paper cut status!) >>> - users vote in jira for reported (on its own risk ;)) and approved >>> paper cuts >>> - depending on the voting (severity) and the difficult level the >>> release >>> manager decides which paper cuts should be fixed in the next xwiki >>> release (see remark below) >>> >>> The important remark to the last point: >>> it's very important to ensure that a certain number of the worst >>> paper >>> cuts will be fixed in any case. Else we can discuss a lot of time >>> about >>> that, but without any effect. Furthermore, without seeing a real >>> progress (live) in the paper cut project we cannot really motivate >>> newcomers to participate in that. Therefore including of the core >>> developer team is really essential. What about the following slogan >>> on >>> the PaperCut page? >>> "XWiki developers promise you to fix every release 10 worst paper >>> cuts! >>> Help by identifying or even fixing much more paper cuts!" >>> The number does not matter here, just replace it with a realistic >>> one. >>> XWiki developers could pick up more difficult issues and let fix >>> easy/trivial issues by newcomers. >>> >>> Best regards, >>> Roman >>> >>> >>> >>> >>> Am Samstag, den 19.09.2009, 22:02 -0400 schrieb Caleb James >>> DeLisle: >>>> As far as I can see, a "paper cut" meets 2 criteria: >>>> >>>> 1. It is easily repaired, devs will know this, users may not. >>>> >>>> 2. New users tend to bump into it while learning the interface. >>>> New >>>> users will know this but devs may not. Devs will be very adept at >>>> navigating the system and will be able to (without noticing) avoid >>>> issues which will cause trouble for new users. >>>> >>>> If I were naming them I would call #1 trivial issues, and #2 >>>> "sharp >>>> edges". To satisfy criteria 2 an issue doesn't even need to be a >>>> bug, it could just be a UX idiosyncrasy. >>>> >>>> I have reported a few bugs which are trivial to repair, but very >>>> difficult to detect, definitely not in the first day :) >>>> >>>> Those are my thoughts. >>>> >>>> Caleb James DeLisle >>>> >>>> >>>> Vincent Massol wrote: >>>>> On Sep 19, 2009, at 11:25 PM, Ecaterina Valica wrote: >>>>> >>>>>> The "original" Ubuntu paper cut definition >>>>>> >>>>>>> Put briefly, *a paper cut is* *a trivially fixable usability >>>>>>> bug >>>>>>> that the >>>>>>> average user would encounter on his/her first day of using a >>>>>>> brand >>>>>>> new >>>>>>> installation of Ubuntu Desktop Edition* >>>>>>> >>>>>> so the papercut is so much trivial than it is an usability bug. >>>>>> >>>>>> How can he tag with papercut if he doesn't know if it's a >>>>>> trivial >>>>>>> issue (since the definition of a paper cut is that it's a >>>>>>> trivial >>>>>>> issue)! :) >>>>>>> >>>>>>>> If the >>>>>>>> developer comes and marks it difficult, we still know that the >>>>>>>> user >>>>>>>> though >>>>>>>> that the issue needed attention and raises an usability >>>>>>>> problem. >>>>>>> I don't think papercut == usability issue. For usability issues >>>>>>> we >>>>>>> should tag them with "usability" IMO since the need is more >>>>>>> general >>>>>>> than just for papercuts. >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>> IMO if we want to make this initiative an user reporting >>>>>> process, it's >>>>>> easier and more intuitive to mark the reported issues with a tag >>>>>> that states >>>>>> the paperCut concept, than to mark it with a difficulty level. >>>>> >>>>> But we also need to know usability issues so we need that >>>>> usability >>>>> tag + we already have the notion of difficulty. It's all about >>>>> the >>>>> amount of work to do. Proposing ideas is easy but following them >>>>> up is >>>>> hard to the less new concepts introduced the easiest it is. >>>>> >>>>> Anyway provided you tag with usability and the difficult level >>>>> you can >>>>> also tag with whatever else you want but you should tag at least >>>>> with >>>>> difficulty and usability, that's my point since otherwise we'd be >>>>> dropping what we've already started which is bad and not >>>>> consistent >>>>> and then it'll all be a mess. >>>>> >>>>> Thanks >>>>> -Vincent