9:50 p.m.
OK, I don't get it. What criteria puts an issue in the "no priority
set" list?
Some *do* have a priority set, e.g. #374, but show up in the "no
priority set" list when I select "Show Open". Many are missing an
entry in the Classification section, but issue #2, for instance, is in
the "no priority set" list and has all classifications fields set.
Is there rhyme or reason here?
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:54 p.m.
Arrgh. Stupid operator error. Ignore my comment re issue #2; it is not
in the no priority set list.
So, does this mean that "no priority set" should really say "some
classification fields missing"?
--- Vladimir
on 07/09/2008 01:50 PM Vladimir G. Ivanovic said the following:
OK, I don't get it. What criteria puts an issue in the "no
priority set"
list?
Some *do* have a priority set, e.g. #374, but show up in the "no
priority set" list when I select "Show Open". Many are missing an entry
in the Classification section, but issue #2, for instance, is in the "no
priority set" list and has all classifications fields set.
Is there rhyme or reason here?
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:37 a.m.
Vladimir G. Ivanovic writes:
OK, I don't get it. What criteria puts an issue in the "no
priority
set" list?
What it says: there is no priority set. Good question, though.
Some *do* have a priority set, e.g. #374
Actually, I don't think that #374 does have a priority set. What you
are seeing is the "issue editor" view. In the nature of an editor
interface, the values you see are not the current values, but the
values that the attributes will get if you press "submit changes". Of
course, for most issues those "default edited values" will be
initialized to the current values.
When priority is currently "--unselected--", the default edited value
is forced to "normal" to ensure that priority would automatically get
a sane value as soon as the issue is edited, even though those fields
are marked as "not interesting to ordinary users".
This could be implemented to show the current value in the "issue
editor" view, but automatically force it to "normal" if set to
"--unselected--". It would take a fair amount of effort, though,
because I haven't learned to hack that part of Roundup yet. The
implementation I used just required a 40-byte Python expression. :-)
Now that it's been explained, do you think it would help other users
if I changed it?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:36 p.m.
I think it's unintuitive and surprising for the issue editor view to
show a value that is, in fact, not present. (Is this the default
Roundup behavior?)
Why not label unselected but required fields in red? (I think this is
already done with the Module field.) If the user tries to save the
issue, then an error message can pop up asking the user to fill in all
fields marked with a red label.
My 2 centidollars (unadjusted for inflation).
--- Vladimir
on 07/09/2008 11:37 PM Stephen J. Turnbull said the following:
Actually, I don't think that #374 does have a priority set. What
you
are seeing is the "issue editor" view. In the nature of an editor
interface, the values you see are not the current values, but the
values that the attributes will get if you press "submit changes". Of
course, for most issues those "default edited values" will be
initialized to the current values.
When priority is currently "--unselected--", the default edited value
is forced to "normal" to ensure that priority would automatically get
a sane value as soon as the issue is edited, even though those fields
are marked as "not interesting to ordinary users".
This could be implemented to show the current value in the "issue
editor" view, but automatically force it to "normal" if set to
"--unselected--". It would take a fair amount of effort, though,
because I haven't learned to hack that part of Roundup yet. The
implementation I used just required a 40-byte Python expression. :-)
Now that it's been explained, do you think it would help other users
if I changed it?
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:18 a.m.
Vladimir G. Ivanovic writes:
I think it's unintuitive and surprising for the issue editor view
to
show a value that is, in fact, not present.
OK, I'll see if I can find a way to set the value without this
unintuitive behavior.
(Is this the default Roundup behavior?)
No, as I said, this is an easy hack that ensures priority is set
without forcing the user to do it. Priority is the property primarily
of the assigned developer, so users should normally not be setting it.
Severity is the field that the user can set.
Why not label unselected but required fields in red?
We do. Since users in general should not be setting priority, it can
not be a required field.
If the user tries to save the issue, then an error message can pop
up asking the user to fill in all fields marked with a red label.
As a user, I hate programs that behave that way. I want to keep
fields that require user action to a bare minimum. Currently that
minimum is title and module (severity, type, and platform all have
plausible defaults).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:36 p.m.
OK, I get it now. (duh)
on 07/11/2008 11:18 PM Stephen J. Turnbull said the following:
Vladimir G. Ivanovic writes:
> I think it's unintuitive and surprising for the issue editor view to
> show a value that is, in fact, not present.
OK, I'll see if I can find a way to set the value without this
unintuitive behavior.
Good.
> (Is this the default Roundup behavior?)
No, as I said, this is an easy hack that ensures priority is set
without forcing the user to do it. Priority is the property primarily
of the assigned developer, so users should normally not be setting it.
Severity is the field that the user can set.
I'd leave it unselected and not in red.
> Why not label unselected but required fields in red?
We do. Since users in general should not be setting priority, it can
not be a required field.
> If the user tries to save the issue, then an error message can pop
> up asking the user to fill in all fields marked with a red label.
As a user, I hate programs that behave that way. I want to keep
fields that require user action to a bare minimum. Currently that
minimum is title and module (severity, type, and platform all have
plausible defaults).
--- Vladimir
--
Vladimir G. Ivanovic
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:26 p.m.
Vladimir G. Ivanovic writes:
> Priority is the property primarily of the assigned developer,
so
> users should normally not be setting it.
I'd leave it unselected and not in red.
I don't see why. The only use-case I can see is for a volunteer like
you to go through and set it, almost always to normal. I don't really
see why accurate classification of "priority: unselected" is
particularly important compared to reclassifying bugs that have
incorrect priority, of which there are surely more than a few.
OTOH, there are 43 issues with no module set and no priority set. I
would like to see the modules classified and keywords added. But I
think it would be basically harmless if all of them were set to
priority: normal at once.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5765
days inactive
5768
days old
6 comments
2 participants
participants (2)
-
Stephen J. Turnbull -
Vladimir G. Ivanovic