r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!CureCode] web-based bugtracking tool

Dockimbel
13-Dec-2010
[1132]
About server failures, my server is pretty solid (SSD drives, recent 
hw) and full DB backups are done every day by a batch script on a 
remote  machine (my local home server, a Eeebox ;-)).
BrianH
13-Dec-2010
[1133x2]
Part of the reason that I would like to move to CC for R2 is because 
most of the bugs found in R2 are found during the development of 
R3 nowadays. Even if we have to be more stringent about backwards 
compatibility, we still want the cross-referencing, at least for 
the R2 equivalent of bug #666. Plus, I know CC better.
The biggest UI problem I've noticed is the semantic overlap between 
the severity and priority fields. I've been saying that severity 
is for difficulty and priority is for importance, but then there 
are importance settings in the severity list (crash and block). That 
could stand to be a bit cleaner.
Dockimbel
13-Dec-2010
[1135]
#666: "I don't want to change anything or learn anything new. REBOL 
2 is perfect and nothing should ever change." :-))
BrianH
13-Dec-2010
[1136]
Works for R2 tickets as well, as a backwards-compatibility argument 
:)
Dockimbel
13-Dec-2010
[1137x3]
About severity vs priority: you can see "severity" as an issue property 
while "priority" is a processing workflow property.
In other words, "severity" is set by the emitter while "priority' 
is a field in the hands of the developers.
The UI should better separate those 2 categories. "Priority" should 
have go down with other "developer" fields, but it wasn't very good-looking 
when I tried it at the beginning. I was waiting for more fields to 
be added (for better balance) before moving it down.
BrianH
13-Dec-2010
[1140]
Even if it means changing a lot of tickets, the difference between 
those should be more clear. Using severity to declare difficuty has 
been useful both to decide which tickets to do when and for negotiating 
(not everything can be fixed, and not everything is really a bug). 
But we haven't really been using the developer priorities, because 
there's too many tickets, and because we have been going with more 
of a work flow system instead of a priority system, except for crash 
and block bugs which get higher precedence if we can. Managing priorities 
has been mostly done on a per-developer basis, with me keeping track 
of the tickets as a whole, and Carl doing the big picture.
Kaj
13-Dec-2010
[1141x3]
I agree with Doc that severity is set by the reporter, and should 
thus not be confused with difficulty of solving for the developers
Reporters basically don't care about difficulty, because if they 
could judge it, they could probably also fix it themselves
Developers shouldn't even care much about difficulty, because everything 
should be doable, or they wouldn't be developers, so priority is 
more important
Dockimbel
13-Dec-2010
[1144x3]
I'm upgrading Cheyenne version on curecode.org, if you're editing 
something, better save it right now.
Upgrade done. Changes:

o FEAT: Short URLs for tickets direct referencing added.

o FIX: double escaping of HTML entities in description and comments 
removed.

o FIX: vertical spacing of RSS image when navigation buttons are 
not present.
Ticket 1794 (http://issue.cc/r3/1794) now renders special characters 
correctly.
BrianH
13-Dec-2010
[1147x4]
Some things aren't doable because they are incompatible with REBOL 
on a basic semantic or syntactic level. It is not a matter of developer 
ability, and such requests are made more often than you would think.
Everything is set by the reporter at first, often incorrectly. The 
severity field is a mix of data, some of which affects priority but 
most of which only has bearing on difficulty. I'd like to say the 
priority field is more important, but we have been having difficulty 
making it useful to us, and we mostly track priorities separately. 
Perhaps with some tweaks both of the fields could be more useful 
to us.
We do need a field that contains information about the scale/difficulty 
of the problem, and that is what we have been using the severity 
field for in the R3 project. Basically, anything that requires just 
a tweak to help strings or error messages gets text; then there's 
simple tweaks or minor fixes; new datatypes or fundamental changes 
to major functions gets major; requests to changes in basic evaluation 
semantics gets major, or dismissed, depending on the possibility 
of such a change (some are impossible without breaking REBOL completely). 
The other settings (crash and block) are actually severity. We use 
those levels of difficulty to schedule fixes or in some cases defer 
until later.
We don't really have a field that we are using to state the importance 
to the reporter of the bug, but that is obvious from the description 
and comments, and we set the priority field accordingly. I would 
like a better approach than this, so if the description of our practices 
helps in any way then that would be great.
Kaj
13-Dec-2010
[1151x2]
Thanks for the quick fix, Doc ;-)
I don't oppose the developers using a difficulty field, but using 
severity for it is misleading to users, and frustrating when seeing 
it changed, because that seems to ignore their concerns
BrianH
13-Dec-2010
[1153x2]
We were using it for the severity of the problem/wish itself, not 
for the severity of the problems that were caused to the users by 
the problem. A problem that requires a new datatype is a pretty severe 
problem - we only have the possibility of a limited set of those. 
Typesets are immediate values, not structures.
But the confusion is pretty awkward.
Kaj
13-Dec-2010
[1155]
Yes, I understand, but the field is still mislabled
BrianH
13-Dec-2010
[1156x5]
Yup. I think that it should be two fields. At this point we have 
so much to do that the only way we can really judge priorities based 
on user need is through comments left on the ticket by other people. 
There is just too much to do, and too many unanswered questions, 
and a lot of stuff just needs to be put off until we can do it. Once 
we get past the first release we will be better able to just fix 
things when they go wrong. For now, we assume that anything short 
of a crash or block was at least important enough to report, so it 
should be considered.
This means that for now even if there is a user-need field, we pretty 
much need to ignore it because we have to assume that all tickets 
are important. In many cases the person who reported the problem 
doesn't realize how important it is. It's only in the discussions 
that the real importance becomes clear.
For instance, the main criteria for priorities at this stage of development 
is whether the ticket affects basic semantics of the language, or 
crashes the interpreter. Any such changes need to be done before 
the first release, or else code might be written that depends on 
the old semantics. By that standard, the importance to the submitter 
is of limited scope in comparison to the importance to the whole 
community. This is not to diminish the need of an individual user, 
this is just the stage we are at.
The other thing that gets something bumped up in priority at this 
point is whether it is an easy fix, for great user benefit, and applies 
to functions or code that we are going over for other reasons now 
anyways. Your DELINE bug is one of those, Kaj. There are more severe 
bugs in that function that have already put it on the priority list, 
your reported bug should be easy to fix too, it affects a real current 
user base in a significant way, and it hints at the possibility of 
a worse hidden problem. These combined make #1794 a near-term priority.
Of course we could tell all of that from the description :)
Kaj
13-Dec-2010
[1161x3]
I don't oppose changing the submitted severity according to some 
standard, either. Just the misnamed intention of the field
For example, that DELINE bug. I circumvented it, so it's not critical 
to me anymore. But I could only choose between minor and major, so 
I thought for someone trying to process Slovenian text, it would 
be a major problem. If there had been an option "normal", I would 
have chosen that
Then you changed it to minor. I reverse engineered that action to 
conclude that you interpreted the field as severity for you instead 
of severity for the user
BrianH
13-Dec-2010
[1164]
Yup, that is how we have been treating that field. Severity for the 
user always varies based on their own circumstances.
Kaj
13-Dec-2010
[1165]
So you were communicating that it was difficulty minor, so easy to 
fix. But to most people, I'm afraid, it would appear as dismissing 
their major problem as being minor
BrianH
13-Dec-2010
[1166]
Which is why I have to explain this a lot. I have written at least 
a dozen ticket comments to this effect.
Kaj
13-Dec-2010
[1167]
It would be a lot easier to just use fields according to their lable 
:-)
BrianH
13-Dec-2010
[1168x2]
I try to not do this all the time as it gets tiresome, and at some 
point the UI problem will be fixed.
I *do* use the fields according to their label. Severity is severity. 
The severity of the user's problem can't be explained without context 
- a field would be useless, you have to give the context in the description 
or comments. The severity for the developers can be expressed in 
a field though, as the context is just the language itself.
Kaj
13-Dec-2010
[1170]
As I said, I'm OK with adjusting it to a standard. But that would 
still be severity to the overall community, not severity to the developers. 
Nobody is interested in that
BrianH
13-Dec-2010
[1171]
Except the people actually using CureCode to determine and plan fixes 
and changes. The people to whom those fields matter.
Kaj
13-Dec-2010
[1172]
You're reversing the meaning of the field by changing it from severity 
of the inconvenience of the bug to severity of the inconvenience 
of the fix
BrianH
13-Dec-2010
[1173]
Severity of the change, not some measure of inconvenience. That is 
the main thing that can stop a ticket from being implemented at all, 
the most important field in that group. You are acting like developers 
of the language are more concerned about their own convenience. You 
know that is not the way we work.
Kaj
13-Dec-2010
[1174]
That is exactly what I'm telling you. I'm merely asking you to try 
to think for a moment from the perspective of the users you're asking 
to report issues, instead of your own perspective
BrianH
13-Dec-2010
[1175]
We are in design mode, and for CureCode as well apparently. All tickets 
are important, or else they wouldn't have been reported.
Kaj
13-Dec-2010
[1176x2]
Come on, then you should just remove the field
If you want to keep explaining yourself to unsuspecting users, I 
apparently can't stop you
BrianH
13-Dec-2010
[1178x3]
We need to break it into two fields. One for the users to report 
their damage, one for us to use for determining the severity of the 
problem (whatever you want to call that). The user damage field wouldn't 
help us much in the process of fixing the user's problems or satisfying 
their requests, but users apparently expect one. We would get the 
real info from the summary, description, example code and comments, 
same as we do now. Without those details the importance of the fix/enhancement 
to the user is impossible to determine, but with those details we 
can really work on the user's problems and understand their priorities.
Keep in mind that I am not suggesting that this be called a "user 
damage" field. I think that it shouldn't be called "severity", because 
that only applies to bugs and issues. Perhaps "importance" would 
be better, as it applies to notes and wishes as well.
We still don't have a good way to set priorities in CureCode though, 
for planning releases. We have to do it manually. The CC priority 
field is OK for general priorities, but not for our priorities because 
our priorities vary from release to release, depending on what area 
of the code we are focusing on.
Kaj
13-Dec-2010
[1181]
If a user lables a bug as "crash", that's significant enough, and 
Carl always wants to fix those first