Hi,
Having heard your points, I can see that a direct interface for the user to
"trick" the priority to be higher isn't a good idea. Maybe instead we could
have some of those priority-related questions go into the description as it
is generated (such as "Does this break a major point of functionality," or
"Does this make OOo unuseably slow"). These questions would be listed with
checkboxes and appear in the description as a line that says something like
"User reports that issue breaks major funcionality: true". (Or would this
make the simple interface too complicated?) That way a QA volunteer can see
more easily where an issue should get a priority upgrade without giving the
user a way to "trick" the priority.
My feeling is, that we will bring in complexity in again by doing this.
I'd rather have those rules documented for QA members, so that priority
is correctly choosen in the second step.
Although this begs another question... when the simple interface is
created, will the advanced (current) interface still be available to all
users? If so, then malicious users filing a new issue could just go to the
advanced interface and trick the priority there by setting it higher. If we
want to avoid that problem completely we would have to revoke access to the
advanced interface from regular users...
The full interface should be available. And I'd guess it must be the
last step for reporting an issue anyway.
I don't think, we need to revoke access to the interface. (Hey, we are
an open project, completely revoking access would hurt more than it
would help.) The idea is to have a way to report bugs that fits the
users needs. And as we have dufferent users, we should have different ways.
andré
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
