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