What my company does is that once a bug is reported, someone in R&D will then look at the bug and verify it. Once verified, we add a comment to the notes stating that the bug is verified and in our company we then also assign it to the person that is most likely going to fix it. If another person comes along and sees the bug is still open and decides they want to fix it, the first thing we do is contact the assigned person to see if they are actively working on it. If they are then there is no need for the new person to work on it. This works for us because we are all in the same time zone. With everyone on the project spread around the world, this way of doing things might not work well. It could take a couple of days to get a response from someone about if they are actively working a bug or not. By then, the new person might have lost interest in fixing the bug or has moved on to something else. In my opinion, the only way to allow for unobstructed fixing of bugs by anyone, is to leave them unassigned and when someone starts to work on it, they assign it to themselves. This tells everyone else that the bug is actively being worked. I don't think it's too much trouble to ask someone to read the notes of a bug before starting to work on it to see if there might be something in them like "This is related to another bug I am working on, so once I get that one fixed I'll clean this one up too". This tells me that the bug is not actively being worked but someone knows about it. I wouldn't try to work on this one with a note like that. If the only notes said that the bug has been verified, nothing else, then this bug is up for grabs and I could then assign it to myself and start working on it. And at that time it wouldn't hurt to add a quick note to the bug stating that you are starting to work on it just to clear up any confusion. I think there are 2 points that we need to address here, the first is that we can quickly identify bugs that are not currently being worked on so that we can look at those and see if we want to work on them. And the second is that we don't duplicate efforts. It would be a shame for two people to start looking at a bug at the same time and both spend a lot of time on it just because they saw that it has been assigned to Sebastian for the past 3 weeks but is not resolved. Then both go to post their fixes only to find out that a fourth person already posted a fix for that bug while you were working on it. The notes field for each bug is going to be a very important area for everyone to use. As someone starts to work a bug I feel it is vital that they update the notes during the process so that everyone else knows what is going on and to keep others from waiting their time working a bug that is almost fixed by someone else.
I feel that as long as a quick note is left stating that the bug is verified would be all a reporter would need to know that at least someone has looked at it. They are not going to get their feelings hurt if the bug stays unassigned until it gets actively worked. We are all adults, efficiency is more important then egos at this stage of the game.

This is just my opinion, I could be wrong.

Jim

On 6/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Sebastian Werner <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] schrieb:
>> Sebastian Werner <[EMAIL PROTECTED]> writes:
>>
>>> The problem is how to tell the reporter that his bug was read and was
>>> marked as TODO. I really like assigned because it tells the reporter that
>>> I've seen the report. Also it doesn't look really supportive to just to
>>> not react on new bugs. With the STATUS change to ASSIGNED the reporter get
>>> some positive feedback. Or I could even directly close it as INVALID. But
>>> just do nothing looks a bit lame in my opinion.

>> Although "It's always been done that way" is a lousy reason for continuing
>> to do something, in this case, "It's always been done that way" and it
>> seems to work.  My experience with other open source projects is that bugs
>> are left as NEW until someone is ready to work on one.  As long as it
>> doesn't take months to get to working on bugs, leaving them as NEW for a
>> few days or even weeks shouldn't be a problem.
>
> Mhh, I haven't written this: "It's always been done that way". Also it was
> not meant this way, if you think so. I just want to say, that if I would
> like to have a STATUS change to show the reporter that we have seen the
> report.

No, sorry, I wasn't implying that you had said it.  *I* said it, meaning that
with other projects that I've been involved with, "the way it's done" is to
leave the status at NEW until someone claims the bug as their own.  No one
else should work on a bug that is marked as ASSIGNED in these other project.
What I'm saying is that that method (leaving it at NEW) works well on the
other projects.  That's "the way it's always been done".

> I will discuss this further with Andreas. Maybe we leave new bugs as NEW.

Ok.

Cheers,

Derrell

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to