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 > > > _______________________________________________ > > > users mailing list > > > users@xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/users > > > > > > > _______________________________________________ > > users mailing list > > users@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
