Re: [xwiki-users] Paper Cut draft

Hi Vincent,

please review the Paper Cut draft (beta): http://dev.xwiki.org/xwiki/bin/view/Drafts/PaperCut

If you agree, please create the field "Paper Cut" in JIRA projects with the following values: - reported - approved - rejected Default value: None

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