[xwiki-users] [XWIKI-4375] xwiki paper cuts
Hello, I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375 <description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;) The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description> I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated. Best regards, Roman
On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
Hi Roman, (some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core): • Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... • Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... Here's some work to be done IMO: • Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks -Vincent PS: I'm not sure XWIKI-3335 is that trivial... :)
On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote:
On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
Hi Roman,
(some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core):
• Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
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
• Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... Here's some work to be done IMO:
• Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks
-Vincent
PS: I'm not sure XWIKI-3335 is that trivial... :)
Feel free to start a PaperCut page on dev.xwiki.org
done: http://dev.xwiki.org/xwiki/bin/view/Main/PaperCut Currently this page is linked from the page "": - XWiki Project Health: http://dev.xwiki.org/xwiki/bin/view/Community/Project+Health - Contributing: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing P.S I will do my best, regarding as always available time. Best regards, Roman Am Samstag, den 19.09.2009, 18:28 +0200 schrieb Vincent Massol:
On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote:
On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
Hi Roman,
(some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core):
• Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
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
• Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... Here's some work to be done IMO:
• Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks
-Vincent
PS: I'm not sure XWIKI-3335 is that trivial... :)
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Sep 19, 2009, at 7:14 PM, Roman Friesen wrote:
Feel free to start a PaperCut page on dev.xwiki.org
cool
Currently this page is linked from the page "": - XWiki Project Health: http://dev.xwiki.org/xwiki/bin/view/Community/Project+Health
I'm not sure about the link from project health. That page was to give stats about the project health. WDYT?
- Contributing: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing
Yes this is good and where I'd have put it. Thanks -Vincent
P.S I will do my best, regarding as always available time.
Best regards, Roman
Am Samstag, den 19.09.2009, 18:28 +0200 schrieb Vincent Massol:
On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote:
On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
Hi Roman,
(some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core):
• Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
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
• Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... Here's some work to be done IMO:
• Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks
-Vincent
PS: I'm not sure XWIKI-3335 is that trivial... :)
Hi, I think this initiative is great and will help improved our UX. The paper cut issues could be great for anyone wanting to start participating in open source and want a small bug to fix (like GSOC students :p ) Related jira issues could be just linked to this jira task.
Instead of linking them we could tag them with paperCut, maybe we like this approach better. User could tag the issues with paperCut and developers should rate the issue's difficulty and priority. Regarding
Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
we are targeting just the issues in the CORE? there are lots of trivial issues in other components. Thanks, Caty
On Sep 19, 2009, at 11:00 PM, Ecaterina Valica wrote:
Hi,
I think this initiative is great and will help improved our UX. The paper cut issues could be great for anyone wanting to start participating in open source and want a small bug to fix (like GSOC students :p )
Related jira issues could be just linked to this jira task.
Instead of linking them we could tag them with paperCut, maybe we like this approach better.
User could tag the issues with paperCut and developers should rate the issue's difficulty and priority.
I don't see the difference between a "papercut" tag and the "trivial" difficulty. Could you explain?
Regarding
Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
we are targeting just the issues in the CORE? there are lots of trivial issues in other components.
See my previous mail. I mentioned the need to have the difficulty custom field in other jira projects too... Thanks -Vincent
On Sat, Sep 19, 2009 at 23:09, Vincent Massol <[email protected]> wrote:
On Sep 19, 2009, at 11:00 PM, Ecaterina Valica wrote:
Hi,
I think this initiative is great and will help improved our UX. The paper cut issues could be great for anyone wanting to start participating in open source and want a small bug to fix (like GSOC students :p )
Related jira issues could be just linked to this jira task.
Instead of linking them we could tag them with paperCut, maybe we like this approach better.
User could tag the issues with paperCut and developers should rate the issue's difficulty and priority.
I don't see the difference between a "papercut" tag and the "trivial" difficulty. Could you explain?
The idea is that if it's a user submitted issue, the user might not know the difficulty of the issue and he will just mark it with the tag. 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.
Regarding
Trivial:
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
we are targeting just the issues in the CORE? there are lots of trivial issues in other components.
See my previous mail. I mentioned the need to have the difficulty custom field in other jira projects too...
Thanks -Vincent
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
On Sep 19, 2009, at 11:13 PM, Ecaterina Valica wrote:
On Sat, Sep 19, 2009 at 23:09, Vincent Massol <[email protected]> wrote:
On Sep 19, 2009, at 11:00 PM, Ecaterina Valica wrote:
Hi,
I think this initiative is great and will help improved our UX. The paper cut issues could be great for anyone wanting to start participating in open source and want a small bug to fix (like GSOC students :p )
Related jira issues could be just linked to this jira task.
Instead of linking them we could tag them with paperCut, maybe we like this approach better.
User could tag the issues with paperCut and developers should rate the issue's difficulty and priority.
I don't see the difference between a "papercut" tag and the "trivial" difficulty. Could you explain?
The idea is that if it's a user submitted issue, the user might not know the difficulty of the issue and he will just mark it with the tag.
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
Regarding
Trivial:
http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
we are targeting just the issues in the CORE? there are lots of trivial issues in other components.
See my previous mail. I mentioned the need to have the difficulty custom field in other jira projects too...
Thanks -Vincent
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.
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
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
Hi Roman, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
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
Best regards, Roman
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
I'm not sure about the link from project health. That page was to give stats about the project health. WDYT? I think, if a project take care even about small usability issues (paper cuts), it's a _very_ good sign of the project health. Probably the current title "Project Health" does not meet the content of the page, what about "Project Stats"? Anyway feel free to remove the link from the page ;)
Best regards, Roman Am Samstag, den 19.09.2009, 19:19 +0200 schrieb Vincent Massol:
On Sep 19, 2009, at 7:14 PM, Roman Friesen wrote:
Feel free to start a PaperCut page on dev.xwiki.org
cool
Currently this page is linked from the page "": - XWiki Project Health: http://dev.xwiki.org/xwiki/bin/view/Community/Project+Health
I'm not sure about the link from project health. That page was to give stats about the project health. WDYT?
- Contributing: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing
Yes this is good and where I'd have put it.
Thanks -Vincent
P.S I will do my best, regarding as always available time.
Best regards, Roman
Am Samstag, den 19.09.2009, 18:28 +0200 schrieb Vincent Massol:
On Sep 19, 2009, at 6:27 PM, Vincent Massol wrote:
On Sep 19, 2009, at 6:22 PM, Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
Hi Roman,
(some comment I put on the jira issue but are better posted here) Great idea. We had started something similar but now you've given it a name: a Paper Cut. What we've done so far was to identify easy to fix bug and mark them as easy in jira. For example here's the current list of issues marked as trivial in XWiki core (we need to extend this notion to all jira projects right now I think it's only in core):
• Trivial: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10...
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
• Easy: http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10... Here's some work to be done IMO:
• Review existing issues and verify the difficulty is correctly set • Add these custom fields to all projects in jira • Prepare a page on dev.xwiki.org to explain this Paper Cut thing • Promote it on the xwiki mailing lists, twitter, etc Thanks
-Vincent
PS: I'm not sure XWIKI-3335 is that trivial... :)
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
Hi Marius, you have my vote. Thank you, Roman Am Sonntag, den 20.09.2009, 09:39 +0300 schrieb Marius Dumitru Florea:
Hi Roman,
Roman Friesen wrote:
Hello,
I have just created the jira task "XWIKI-4375": http://jira.xwiki.org/jira/browse/XWIKI-4375
<description> As you probably know the Ubuntu team has starter the project "One Hundred Paper Cuts": https://launchpad.net/hundredpapercuts
They define a paper cut as (https://wiki.ubuntu.com/PaperCut): * a bug, or an unintended problem occurring within an existing piece of software, * the presence of which makes a computer more difficult or less pleasant to use, * that is easy to fix, * that the average user would encounter during his/her first day of using
XWiki is a great software but it contains also a lot of "paper cuts". Such little but annoying bugs or usability issues would be a great entry point for new xwiki developers, because they are easy to fix. But also experienced xwiki commiters could relax fixing this paper cuts after their hard work ;)
The proposal would be to start a similar task/project for identifying paper cuts in xwiki. Related jira issues could be just linked to this jira task." </description>
I have already linked one paper cut to this jira task - XWIKI-3335. Any feedback would be very appreciated.
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
Best regards, Roman
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
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
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 [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
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
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. 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? > 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) - 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 > > 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
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
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 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
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/
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
From a "marketing" point a view it's more easy for the reporter (user) to 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
participants (6)
-
Caleb James DeLisle -
Ecaterina Valica -
Guillaume Lerouge -
Marius Dumitru Florea -
Roman Friesen -
Vincent Massol