[Seaside-dev] protocol for working on Seaside issues

Julian Fitzell jfitzell at gmail.com
Mon Sep 8 20:51:09 UTC 2008


I would like to further ask that developers try to remember to assign
new issues to "nobody" when they are creating them unless they believe
that they alone should fix it. There's a big difference between having
"started" an issue and intending to be the one to fix it. The first
means "don't touch it, I'm doing it" and the second means "don't worry
about it unless you're keen, I'll get to it". A bug may also be
assigned to someone because another developer felt they were the
appropriate person to work on it.

I find it frankly irritating the google decides to auto-assign all
issues to the creator (if they are developers) and there is no way to
change this default. Still it's not that hard to remember to change
the owner to empty if the issue is not merely a "todo" reminder for
yourself.

Julian

On Mon, Sep 8, 2008 at 8:28 PM, John O'Keefe
<wembley.instantiations at gmail.com> wrote:
> Thanks for the explanation (and for gently explaining to this rookie that he
> missed a step).
>
> John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.
>
>
> On Mon, Sep 8, 2008 at 2:21 PM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>>
>> Hi list
>>
>> There seems to be some confusion about what the protocol for working
>> on Seaside issues is.
>>
>> Here's what happened
>> - John created an issue
>> http://code.google.com/p/seaside/issues/detail?id=133
>> - He assigned it to himself and though that would tell everybody that
>> he works on it.
>> - I saw the issue and fixed it while John was working on it at the same
>> time.
>>
>> My excuses to John for stealing the issue. I think he followed the
>> correct protocol and I didn't. To explain myself a bit more:
>> I the past I acted the same way on several assigned bugs and that
>> never caused a conflict. At not time to my knowldge was somebody else
>> working on one. I think mainly because if you create an issue, you'll
>> automatically be owner.
>>
>> To avoid such conflicts in future I propose that we set the issue to
>> started if we started to work on it or we plan to fix it shortly.
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>


More information about the seaside-dev mailing list