Hi guys, I think the papercut idea is good too. Roughly defined, papercuts are UX issues reported by users that are trivial to fix for developers. I think the best way to translate that into XWiki's JIRA is to use the UX keyword and to create a "Paper Cut" filter that lists all issues that have their difficulty field set to "trivial" and the UX keyword.
I think this solution would be ok for both of you :-) On Sun, Oct 4, 2009 at 1:30 PM, Roman Friesen <[email protected]> wrote: > 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. > > > What kind of contribution would like to bring? Providing patches? > > Marking issues? > Reporting and marking issues, documentation, promoting (for example, > regularly status reports on the user mailing list). > > > What we need is an agreement for how we tag usability issues: > > - with the "usability" keyword > > - with the "ux" keyword > > - with something else > 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 > I'm +1 for the "UX" keyword. I think it's easy enough for users to apply it to an existing issue. Guillaume > > I think it's interesting to be able to see trivial issues > > independently of usability issues and vice versa. > 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... > > > > What kind of contribution would like to bring? Providing patches? > > Marking issues? > > > > Trivial issues: > > > http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010&customfield_10060=Trivial&sorter/field=issuekey&sorter/order=DESC > > > > What we need is an agreement for how we tag usability issues: > > - with the "usability" keyword > > - with the "ux" keyword > > - with something else > > > > 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 > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
