Issue Tracker (IssueZilla) is a proprietary version of Bugzilla maintained by CollabNet as part of the 
ensemble of applications known as CollabNet Enterprise Edition (CEE).  We can do some changes but 
not a whole lot, as we do not have much control over things.  

We have notified CollabNet repeatedly of the desirability of an easier UI for new users, and we have also 
made some changes with standard queries.  However, obviously, more can be done. I think it 
worthwhile, however, to evaluate who would be using a simplified UI (if we could do it easily) and who 
would then be reading through the possible wave of submissions--and how.  It would also be useful to 
know exactly how it is hard--where the weaknesses lie and why, and thus how and why things can be 
improved.

One suggestion is to refine the standard queries and to make it a little easier. But one thing you cold do 
James is to offer a quick comparison of, say, Mozilla, Ubuntu, Plone wrt bug/issue filing, so that we can 
see how others do it, too.
thanks
louis

Filing an issue is simple enough and should not be made easier.

Querying IssueTracker is hard - in fact the only simple way I have found is 
via http://www.openoffice.org/project/qa/issue_handling/pre_submission.html

@kpalagin:

You must be much smarter than I.  I misfiled a report the other day.  We have
users that have just purchased a new computer (and it is their first) and then
find our Issue Tracking system very intimidating, to say the least.  My proposal
is that they do the following:
1.  Report what they were doing when the problem occurred. 
2.  Report their name and e-mail address.
3.  Report which operating system and processor in their system (and we can
even give them drop down lists to work with.)
That is it.  Simple.  We who do QA triage determine if:
1.  The fault is repeatable.
2.  Which section of the program the fault appears in.
3.  If a new user would abandon use of OpenOffice.org or not (there are really
only three levels of problems, ones that stop work, ones that are real pains to
work around and those that are called snivels and really only affect a very
small audience and might be easy to fix.)  The first are commonly called
'showstopper' bugs.
4.  Provide additional information, if needed.  If we cannot provide this, we
gently ask the reporter for more information.  If we cannot reproduce the error,
this might be due to the fact that the reporter failed to give us some facts.

Why do this?  Because the quality of reports is low.  There are many issues with
the code "needs more information".

As to the problem with the issue query, please open a new issue for this.

James McKenzie

@louis:

I work in the industry.  We take calls and work through the web with hundreds of
users.  A simple drop down listing of problems will not fix this, however asking
questions and gathering them into the Issue Tracker is the best way.  Most
people filing an issue will do so only once unless they find the experience
'pleasant'.  Thus we may have to completely redesign the Issue Tracker to make
it easy on both the submitter and the QA triage folks.  I'm sorry, but I feel
that hiding behind another company is just an excuse, not a solution.
James McKenzie

James, 
Your hostility is unwanted and unneeded. 
Louis

Quiet down guys, please.

We could have more pleasant ways of adding new issues.
Some of them can to be made without any change to the system (passing parameters
in URLs built via Javascript), but that would require a lot of work.

I would like to see a newer version of Bugzilla in work, but I know it depends
on CollabNet.
Also we can't make much dynamic pages outside services.


We should at least be able to promote our existing pages to more visible places
before redesigning them.
It's a good idea to have a different one for the starters, indeed.

*** Issue 103841 has been marked as a duplicate of this issue. ***

My 2 cents on this.

Sum up of my comment:
- We don't *want* it to make "easy" for anybody to report a problem.
- We *want* qualified reports to make things move on

My background:
I am QA Engineer for OOo so my daily job since more that 12 years is (among
other many tasks!) to receive, analyze, reproduce and, if needed, re-write
incoming issues for the development.

The problem (very short summed up?): does "people happy with us" (easy bug
report) makes them really happy in the long term and resolves their problem
(easy and fast bug fixing)?

It's a question of point of view but I think about: "what do you really want?"...

A metaphor now...

My heart pains and I can't breathe but:
- I don't WANT to GO to the doctor because it's far away
- (ok I am there but...) I don't understand what he says with "put your closes
off!", I don't want to do such thing and anyway I don't know how!
- Now he tells me to take those pills but I have no time for it and it's too
complicated!

That's how I receive this enhancement.... From the reporter's statement I get
that the people reporting here should have 3 fields to answer and that's all!

My answer is:
1. OOo is a FREE project: "Don't *expect* anything but get maybe more!"
2. IssueZilla is a Bug/Feature tracking system, NOT a support media: people here
won't get answers to their questions or that we fix their problem now! We don't
answer questions and don't "help" people.

So the first problem is the re-direction to the correct media and the
understanding of the system:
- On Support media (http://support.openoffice.org/index.html), people help
people in solving their problems.
- On IsueZilla: People help *US* resolving their problems in a long run.

That's a difference I'd see between a "Community" "helping" actively each other
and "Customers" waiting for a "service".

This is a huge difference!

So my personal point of view is: it doesn't matter if our system is complicated
and only "the right people" get their way into it, we don't WANT "the mass" to
spam us with unqualified requests, for which we don't get answer to our
questions during weeks and are still unqualified.

Let me explain an other way...

In a lot of IT companies you have:
- a 1st level support: Supporters calming down people, taking care about them,
proposing workarounds. *reproducing* the case and THEN forwarding to the next
level...
- a 2d level support (actually the QA): analyzing the submission and
re-assigning to the right developer and the right target.

Currently we, QA people, get all the "trash" (sorry for the expression, but it's
quite true...) of the people "who make it into the system", so I'm not eager to
see more unqualified statements here...

To help the people "finding" their diseases we need to know "where" it pains and
see the body. What you propose is "I have a pain but guess what! I don't say more!"

Though I agree IZ is too complicated, this issue, the way you express it doesn't
serve the users but only marketing goals.

So I'll close it as WONTFIX.

(Remember the you can reopen it IF you make a qualified statement ;) )

closed

Another way to express what I feel is:
We have already too many people reporting that what we don't want and we would
like to focus on the "Elite" who reports things the way we CAN fix it. 

Put myself and rbircher on CC.

@es:
Let's see, you started with OpenOffice in 1997 (my math is that good), I started
with StarOffice for OS/2 in 1992, so that makes me a little older than you. 
Also, OpenOffice is not the only FOSS project that I work with and they all
suffer from the same problem, Issuzilla is very hard for the new user to
understand, but is GREAT for the developers who have to work off bug reports. 
Adding a front end so that a user can select from a series of problems is not
undoable and may actually result in better reporting (BTW, I work for a large
corporate organization that is going down that path because of the possibility
of over 100,000 very inexperienced users having access to their bug tracking
system.)
The problem as I see it, is inertia. You have to be willing to accept that
things will change and that Issuezilla has been the topic of some very
interesting discussions on the User forum/mailing list.  Also, how much real
work would it take to resolve this issue?  You could ask questions like:  Did
you search for issues like yours?  Does this issue stop your organization from
completing daily work?  Several others like this could actually make submission,
triage and problem resolution easier, not harder and also encourage users to
submit issues rather than shy away.
I would consider re-opening this issue and examining it very closely from the
user/customer point of view with a developer scope.  This enhancement request
might just make your job of QA/development easier and bug triaging a quick and
painless process.

"Let's see, you started with OpenOffice in 1997..."

My point was not say: "Hey, Buddy! Look at my years of experience an how old I
am!". I just meant to present myself and to say that, yes, I might know better
then others what we can handle an what cannot be done in THIS project.

Else, "experience" and "age" is never a valid argument because I'm ready to
listen to a 14-years old something (If you wanna know I am "only" 38!) as long
as has he has *arguments* and concerning "experience" (which has nothing to do
with the age!): "Experience is only worth what you have made of it"...

So let's forget that point...

"The problem as I see it, is inertia. You have to be willing to accept that
things will change and that Issuezilla"

You don't answer my arguments.

I'd LOVE to change IZ!! It has so many glitches! But the thing is that you want
to make IZ accessible to ANYbody who wants to report ANYthing in a way we cannot
handle it. And that's what we don't WANT (not "can").

"You could ask questions like:  Did
you search for issues like yours?" 

Sorry, but when you click on "NEW" (Issue) you land there:
http://qa.openoffice.org/issue_handling/pre_submission.html

And there is a bold title saying:
"Did you check if your problem is already reported?

Unfortunately, too many issues get reported twice (or much more often). You, as
the submitter who exactly knows the problem, often are much faster in finding
the duplicates than other people. So please take some minutes to see if your
problem is already reported. If so, you can add yourself to the cc-list of the
issue, to be notified whenever something in this issue changes (e.g. when it's
fixed): "

Apparently, you are falling into the category of the people who we don't want:
those who don't read warnings and help texts!

"Does this issue stop your organization from
completing daily work?"

This question is subjective and not objective: everybody's defect or enhancement
is critical as soon as someone made the effort to report it!
The problem is to see what WE can fix and how it fits into the "Big picture"!

If someone reports: "It's part of our corporate identity to have hatching
background on invoice letters and your software doesn't support it"... Fine! But
who cares about this requirements in regards to all those who DON'T need that?
So there, the flag "critical" will be changes into "normal" 

It won't be closed but will not be prioritized...

"Several others like this could actually make submission,
triage and problem resolution easier, not harder and also encourage users to
submit issues rather than shy away."

It won't make it easier but be a useless flag.
Believe me: 80% of the newcomers (those who you want to catch) don't read
indications, flags an warnings: They just want it simple as you describe!
Did you ever read a "README"-file...?

Is that soooo difficult to set the version number of the software you are using?
I get 20 times a week "1.0.0" as version which is not possible!
(Yes I know, we should drop very old releases and unused flags but that's not a
justification for the people NOT to read what they are submitting)

Because people (those who you want to include) DON'T READ what we write!

Very rude sum up: "we don't want to read those who don't want to read us!"



A quick and dirty analyze of the current open issues compared with our resources
gives: if we lock IZ now and refuse ANY new submissions we have work for 10
years. What is in this context the place for:
"Rated: critical
"Description: yesterday my software crashed! Fix it!"
???

Please don't mix up 3 different things:
- Feedback: communication tool to make people "feel better" without any action
taken but maybe the UX having a look at it to make statistics.
- Support: help people right now, explaining them what they didn't understand in
the help and in some case escalating as Bug/Feature
- QA (there where every IZ issue arrives): which should only sort and prepare
QUALIFIED and detailed reports for the DEV.

And please don't mix Open Source and closed source. Yes there is a difference
between "customers" and "users".
We expect from "users" qualified submissions while customers pay for an
escalation process. 2 different worlds!