On 9/15/07, Karan Malhi <[EMAIL PROTECTED]> wrote:
> Below is a question regarding unassigned issues .
>
> Here is a scenario
>
> 1. "A" opens an issue and it is unassigned
> 2. "B" starts working on it (issue still unassigned)
> 3. "B" commits the change and fixes the issue. Now "B" wants to close
> the issue, does "B" have to assign the issue to himself first before
> closing it ? If not, then what is the value behind assigning an issue
> to "B" and then closing it (I think I have seen this happen in past
> commits)

The source code belongs to the project. The sole owner of the source
code is the PMC itself that acts on behalf of ASF and such
blahblahblah.

It doesn't really matter who's fixed what as long as an issue is really fixed.

On to the question, when someone fixes an issue it's worth to let
people know who was behind the change so it's easier to ask the person
(the expert) about more details/explanation when it's necessary. Of
course, one could figure out who did what tracing who closed
particular issue, but on the other hand the one who fixed the issue
doesn't have to be the one who closed it.

So, it's recommended to report an issue/task/whatever you work on so
others don't duplicate it and what's more important that a particular
issue is handled at all. Think about users who report issues, but
don't see any changes for ages as far as their important fixes go and
suddenly they're done. I think there's a big difference in assigning
an issue, fixing it and then commit the change and working on an issue
"quietly" (without assigning the issue). Our users want to know when
they can expect their issue reports are taken care of. They'd be
really concerned if we ignored their voice, wouldn't they?

Jacek

-- 
Jacek Laskowski
http://www.JacekLaskowski.pl

Reply via email to