On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote: We could decide that the trivial category we have corresponds to paper cuts. Feel free to start a PaperCut page on dev.xwiki.org Thanks -Vincent

On Sep 19, 2009, at 7:14 PM, Roman Friesen wrote: cool I'm not sure about the link from project health. That page was to give stats about the project health. WDYT? Yes this is good and where I'd have put it. Thanks -Vincent

On Sep 19, 2009, at 11:00 PM, Ecaterina Valica wrote: I don't see the difference between a "papercut" tag and the "trivial" difficulty. Could you explain? See my previous mail. I mentioned the need to have the difficulty custom field in other jira projects too... Thanks -Vincent

On Sep 19, 2009, at 11:13 PM, Ecaterina Valica wrote: 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)! :) 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

On Sep 19, 2009, at 11:25 PM, Ecaterina Valica wrote: 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

Hi Roman, Roman Friesen wrote: Your initiative is good, but IMO the easiest way to promote an issue is to vote for it. Right now XWIKI-3335 has no votes (and nobody watching it, besides me who created it). Regarding XWIKI-3335, it's not hard to fix indeed but it can slow down the editing (navigating with the arrow keys precisely) because the editor will have to make a non trivial test each time you press the left/right arrow key (what's the current caret position? what's the previous/next _visible_ node relative to the current caret position? Is that node a macro container?). I can fix it but I need your vote. Thanks, Marius

Hi Marius, you have my vote. Thank you, Roman Am Sonntag, den 20.09.2009, 09:39 +0300 schrieb Marius Dumitru Florea:

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:

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

Hi Vincent, probably I have been understanding something wrong :) I see following groups in XWiki project: 1) XWiki committers: - core developers like you 2) XWiki users: - providing patches - helping on documentation, translations etc. - other users My suggestion was to make an extra focus on small usability issues, because these remain unattended very often. The question is only, who should fix these? In my opinion, both groups: XWiki committers and users. XWiki committers as a guarantee, that at least a few of such small usability issues will be fixed at any rate. This guaranteed fixes would fill this usability project with a *real* life, attracting more user attention and in the end more users/contributors providing patches (I hope). Else we can mark hundred of issues as usability problems and wait for the first patch all the time... I think, it would be much more a promoting project, because, I suppose, in fact you fix such issues every release too. Reporting and marking issues, documentation, promoting (for example, regularly status reports on the user mailing list). For me it's not really important, the main thing: - it would be easy also for jira inexperienced users, to mark reports as usability issues - we can easy filter it exactly! :) Regards, Roman P.S. There are always more people giving ideas, than people implementing that :D So don't hesitate to say "NO", if you expect more troubles than benefits here :) Am Sonntag, den 04.10.2009, 02:34 +0200 schrieb Vincent Massol: > Hi Roman, > > On Oct 3, 2009, at 5:14 PM, Roman Friesen wrote: > > > Hi Vincent, > > > >> 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. > > Paper Cuts should be maintained by users (approving, voting) like > > me, not by you. > > Sure but same for the difficulty field. We should all maintain it. > > > 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 > > Then I don't understand something. I thought paper cuts were about > contributors doing patches. Isn't that so? If so we always try to > apply all patches but some are harder to apply than others. Simple > patches do get applied quickly whether paper cuts or not. > > > 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? > > I'm fine with anything but I just don't understand what you're > proposing I guess. > > We have a filter for patches (contributors must use the "patch" > keyword to signify a patch and we do it when contributors forget). So > that covers the use case to let committers know when to apply something. > > Now for contributors to know if an issue is a paper cut (ie whether > it's a trivially simple issue or not) there's the difficulty field > already so I see 3 cases: > * the contributor has found an issue marked with a difficulty of > trivial, he can submit a patch for it > * the contributor is interested by an issue but the difficulty is not > set. He thinks it's a paper cut and he marks it as trivial (for ex). > Note that this optional and he can submit a patch without setting the > difficult field > * a user sees an issue he considers a good match for a paper cut and > marks is with a trivial difficult in jira so that others knows about > it and can see it in the jira filter list for paper cuts. > > What am I missing? > > >> 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. > > These ideas are just different things: > > - I suggest to run a project for improving of usability (primarily > > it's good for users) > > I'm all for it. > > > - 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. > > What I was suggesting too was to tag usability issues with the > "usability" tag if need be. Having a jira component for it is also an > option but more limitating I think. > > > I would like to contribute to the usability project, but without > > yours and other xwiki commiters agreement it wouldn't make any > > sense... > > > Trivial issues: > http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&p… > > > I think it's interesting to be able to see trivial issues > independently of usability issues and vice versa. One we agree about > trivial + usability it's easy to do a jira filter. > > > 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. > > I don't understand why you say it's for developers. All I've suggested > is for contributors. > > Roman, note that I'm only voicing my personal opinion in this thread. > I don't represent the xwiki project, committers or anyone else. Just > me. This is a collegial decision so we need to hear what others thinks. > > Thanks > -Vincent > > PS: I'd really like to have you onboard on this but I'm missing the > point it seems since I don't understand why what we currently have (or > close) doesn't fit the need. > > > 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 > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

Hi, Solution 1 (more a developer approach + general): Priorities: Trivial Keywords: usability Saved as a "Public Filter" with the name "PaperCuts" - I don't know to change this, I know only to make "Private Filters" The problem with the first version is that if the user sets the difficulty field to Trivial and he is wrong (the developer will modify it to hard), even if the bug affects the user's work, JIRA will remove it from the Papercuts filter. OR Solution 2 (more an user approach + specific) Priorities: None (if the user don't know how to set the difficulty) | Trivial Keywords: papercut remember to set the tag "papercut" than to set "trivial + usability". Also, having a specific keyword, is more easy too to promote the PaperCut project. Thanks, Caty