I did some rejiggering of the Classifications, Products, and Components
on BZ, namely:
There are no more Classifications.
The Products are Modules, VASSAL, and Website.
Modules are components under Modules.
This seems cleaner overall, but there’s one downside I’ve noticed, which
is that components can’t have their own version numbers. Hence, this
prevents modules from specifying their own version numbers in BZ. This
might only be a problem for VASL bug reports, or maybe no one cares. I
haven’t deleted the VASL and VSQL products yet in case anyone has a
strong opinion on this.
I feel that losing version numbers for module bugs is a pretty big deal.
I’d really like to be able to put version numbers on module bugs so module
releases can follow more or less the same process as VASSAL releases if we
want to.
I.e.
Classifications:
Site
Applications
Modules
Products
Site / vassalengine.org
Applications / VASSAL
Modules / TTA
Modules / VASL
Modules / Awful Green Things from Outer Space
Components
Site / vassalengine.org / forum
Site / vassalengine.org / wiki
Site / vassalengine.org / bugzilla
…
Applications / VASSAL / Editor
Applications / VASSAL / Player
…
Modules / TTA / unknown
Modules / VASL / unknown
…
I know it’s a bit asymmetrical, and for VASSAL there’s an extra unneeded
layer, but this way we’d get version numbers on module bugs which I think is
pretty important.
Now that I’ve said that, module bugs actually need TWO version numbers–one
for the module (which should use the existing version field) and one for the
VASSAL version. Is it possible to create custom fields for certain
categories?
Ken
-----Original Message-----
uckelman
I did some rejiggering of the Classifications, Products, and
Components on BZ, namely:
There are no more Classifications.
The Products are Modules, VASSAL, and Website.
Modules are components under Modules.
This seems cleaner overall, but there’s one downside I’ve
noticed, which is that components can’t have their own
version numbers. Hence, this prevents modules from specifying
their own version numbers in BZ. This might only be a problem
for VASL bug reports, or maybe no one cares. I haven’t
deleted the VASL and VSQL products yet in case anyone has a
strong opinion on this.
I feel that losing version numbers for module bugs is a pretty big deal.
I’d really like to be able to put version numbers on module bugs so module
releases can follow more or less the same process as VASSAL releases if we
want to.
I agree. I (once again) rearranged everything. It’s this way now.
Now that I’ve said that, module bugs actually need TWO version numbers–one
for the module (which should use the existing version field) and one for the
VASSAL version. Is it possible to create custom fields for certain
categories?
You can create custom fields, but it’s global.
Alternatively, I could turn on the Status Whiteboard field where you can put
arbitrary text. Would that work?
Hmmm… It’s a tough call. You sure fields can’t be tied to specific categories? That’s a bummer. I think custom fields would be too much work and ppl wouldn’t use them. There are already so many fields on a bug that ppl ignore, that adding one more (VASSAL version number) is probably not that big a deal. So I’d be inclined to go that route.
Hmmm… It’s a tough call. You sure fields can’t be tied to specific
categories? That’s a bummer. I think custom fields would be too much
work and ppl wouldn’t use them. There are already so many fields on a
bug that ppl ignore, that adding one more (VASSAL version number) is
probably not that big a deal. So I’d be inclined to go that route.
You think that having an extra field is too confusing? Or insufficiently
confusing? I don’t follow.
I’ve been dupe-checking the new bug reports as they come in, on the theory that, because I’ve looked at every stack trace in the tracker, I will be able to spot dupes faster than anyone else.
What I’ve noticed while doing this is that there’s a bit of an impedence mismatch between the workflow I would like and the workflow we have. Namely:
When I’m dupe-checking, I’m trying to kill dupes as fast as I can. This means that I’m not doing any further triaging. I’m not sure whether I should be. My present feeling is that it will take less time overall to kill dupes, and then go back later to finish triaging, with this latter thing possibly being done by someone else.
I wish we had a status for the reports which have been triaged, but not yet assigned. Right now, there’s no easy way to distinguish between bugs which have been triaged and bugs which haven’t. If I’m triaging bugs, then I’d like to search for ones which are new; if I’m looking for bugs to fix, then I’d like to search for ones which have already been triaged. Right now, I can’t do that.
Assignment: Bugzilla enforces that each bug is assigned to somebody. The SF bug tracker didn’t. Now there’s no way to distinguish between bugs which are really being worked on by someone and bugs which aren’t. A natural way to do this would be to have a ‘nobody’ user to which bugs can be assigned.
I’d also like to have a way to distinguish between bugs that I intend to work on and bugs that I am actually working on. For example, 2901 is one of the former, while 2901 is one of the latter, but there’s nothing on the bug page which will tell you that.
I agree with the points you have raised and the proposed solution. It’s not the interface that is the problem, it’s that there are not enough options to match what we do.
I’d also like to have a way to distinguish between bugs that I intend to
work on and bugs that I am actually working on. For example, 2901 is one
of the former, while 2901 is one of the latter, but there’s nothing on
the bug page which will tell you that.
I used to use the Priority on SF for this. The color coding of priorities made it a snap to locate bugs I was working on. I just find Bugzilla very opaque, I can’t find anything.
I’d also like to have a way to distinguish between bugs that I intend to
work on and bugs that I am actually working on. For example, 2901 is one
of the former, while 2901 is one of the latter, but there’s nothing on
the bug page which will tell you that.
I used to use the Priority on SF for this. The color coding of priorities mad
e it a snap to locate bugs I was working on. I just find Bugzilla very opaque
, I can’t find anything.
Hmm. That’s not really what I’d envisioned using priority for, though I
guess it makes sense that you’d be working on the bugs which you’ve set
to the highest priority.
We can color-code search results according to any combination of status,
resolution, priority, and severity we want to just by providing some CSS,
since BZ puts all of those into the class of each element
corresponding to a bug in the search results. I just haven’t set it up
yet. (E.g., the intensity of the background could correspond to the
priority and the intensity of the foreground could correspond to the
severity…)
Do you have a proposal for how it should be done?
(A good way to try out alternatives is is to bring up a search list and
use the Firefox extension Firebug to alter the page’s CSS. That way,
you can immediately see what the effect of your changes would be.)
I used to use the Priority on SF for this. The color coding of priorities mad
e it a snap to locate bugs I was working on. I just find Bugzilla very opaque
, I can’t find anything.
Hmm. That’s not really what I’d envisioned using priority for, though I
guess it makes sense that you’d be working on the bugs which you’ve set
to the highest priority.
The Importance field already implies the priority of the bug from the point of view of Vassal, the priority will just mirror this and it becomes pointless - All High importance bugs will be high priority etc.
I would suggest we use Priority as the Assignee’s priority and color code on this. Vassal Priories are encoded in the Importance field.
One problem with this is you can’t then prioritize enhancements properly - it has always seemed strange to me that BZ includes this in the Importance field.
We can color-code search results according to any combination of status,
resolution, priority, and severity we want to just by providing some CSS,
since BZ puts all of those into the class of each element
corresponding to a bug in the search results. I just haven’t set it up
yet. (E.g., the intensity of the background could correspond to the
priority and the intensity of the foreground could correspond to the
severity…)
Do you have a proposal for how it should be done?
This sounds good. The main use for color coding for me was to find the bugs I was currently working on and see where they where at, therefore, I would mainly want to see color coding based on the priority, where we are using it as the bug owners priority.
The Importance field already implies the priority of the bug from the point o
f view of Vassal, the priority will just mirror this and it becomes pointless
All High importance bugs will be high priority etc.
Do you mean severity here? Importance is serverity and priority together.
Severity and priority aren’t the same—a severe bug could have low priority
because it affects few users, e.g…
I would suggest we use Priority as the Assignee’s priority and color code on
this. Vassal Priories are encoded in the Importance field.
One problem with this is you can’t then prioritize enhancements properly - it
has always seemed strange to me that BZ includes this in the Importance fiel
d.
I think the idea is that bugs get fixed before enhancements are worked on,
but that’s clearly not been the case with us, historically.
“enhancement” is under severity, not priority—so if you’re using priority
the way you say, then this shouldn’t be a problem. Maybe I’m not
understanding what you’re saying.
We can color-code search results according to any combination of status,
resolution, priority, and severity we want to just by providing some CSS,
since BZ puts all of those into the class of each element
corresponding to a bug in the search results. I just haven’t set it up
yet. (E.g., the intensity of the background could correspond to the
priority and the intensity of the foreground could correspond to the
severity…)
Do you have a proposal for how it should be done?
This sounds good. The main use for color coding for me was to find the bugs I
was currently working on and see where they where at, therefore, I would mai
nly want to see color coding based on the priority, where we are using it as
the bug owners priority.
Note that Missing Images are currently dumping a stack trace to the log file
but NOT generating a bug report. There are so many images missing from so man
y modules that every bug report is full of them. Joel, I suggest we stop miss
ing images generating stack traces, it is pointless and just makes looking th
rough log files far more difficult than it needs to be.
This sounds good. The main use for color coding for me was to find the bugs I
was currently working on and see where they where at, therefore, I would mai
nly want to see color coding based on the priority, where we are using it as
the bug owners priority.
What do you think of how it is now?
Priority “high” gets a light red background, “urgent” gets a brighter red
background.
Severity “critical” gets red text, severity “blocker” gets bold red text.
I agree with the points you have raised and the proposed solution. It’s not t
he interface that is the problem, it’s that there are not enough options to m
atch what we do.
I’ve created the TRIAGED status. (I also fixed a problem with the NEW
status—it had somehow become a Closed status rather than an Open one).