3 Oct
2009
3 Oct
'09
12:23 p.m.
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:
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users On Sep 19, 2009, at 11:25 PM, Ecaterina Valica
wrote:
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users The "original" Ubuntu paper cut
definition
> Put briefly, *a paper cut is* *a trivially fixable usability bug
> that the
> average user would encounter on his/her first day of using a brand
> new
> installation of Ubuntu Desktop Edition*
>
so the papercut is so much trivial than it is an usability bug.
How can he tag with papercut if he doesn't know if it's a trivial
> issue (since the definition of a paper cut is that it's a trivial
> issue)! :)
>
>> If the
>> developer comes and marks it difficult, we still know that the user
>> though
>> that the issue needed attention and raises an usability problem.
> I don't think papercut == usability issue. For usability issues we
> should tag them with "usability" IMO since the need is more general
> than just for papercuts.
>
> Thanks
> -Vincent
>
IMO if we want to make this initiative an user reporting process, it's
easier and more intuitive to mark the reported issues with a tag
that states
the paperCut concept, than to mark it with a difficulty level.
But we also need to know usability issues so we need that usability
tag + we already have the notion of difficulty. It's all about the
amount of work to do. Proposing ideas is easy but following them up is
hard to the less new concepts introduced the easiest it is.
Anyway provided you tag with usability and the difficult level you can
also tag with whatever else you want but you should tag at least with
difficulty and usability, that's my point since otherwise we'd be
dropping what we've already started which is bad and not consistent
and then it'll all be a mess.
Thanks
-Vincent
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users