[etoys-dev] jira re-arrangement

[Timothy Falconer]

On Sep 4, 2009, at 5:42 AM, Bert Freudenberg wrote:

> On 31.08.2009, at 15:46, Timothy Falconer wrote:
>> When you click "resolve", the word "complete" means, "my work is  
>> complete".  With small groups, we simply re-open the issue when  
>> someone's test doesn't pass.
>
> Tim,
>
> do we want to always resolve when there is a change set? See chat  
> log below.
>
> [04.09.09 11:11:15] Bert: hi scott: when you attach a fix to jira,  
> our workflow now demands to resolve the ticket. all resolved but not- 
> yet-closed tickets are the ones that need testing. This actually  
> makes some sense ;) http://wiki.squeakland.org/display/sq/Process
> [04.09.09 11:12:19] Scott: yes, I know that, though I haven't been  
> practicing it much ;-)
> [04.09.09 11:12:58] Bert: ah, okay. I thought you forgot, seeing the  
> new attachments
> [04.09.09 11:16:08] Scott: not always clear what to do.  e.g.   
> SQ-267, i posted a fileout that carries out the suggestion of the  
> ticket, but no one ever commented on the ticket, no one ever said  
> yes we should do this.  So I put the fileout onto the ticket but  
> didn't want to "resolve" it without there being some agreement that  
> it was something we wanted.
> [04.09.09 11:17:21] Bert: I understand, but that's only the next  
> step. Resolving means putting up for review now
> [04.09.09 11:17:53] Bert: and the milestone should be changed to the  
> current one too if we want to deal with it soon.
> [04.09.09 11:19:15] Scott: So in the case of sq-267 you think I  
> should "resolve" it?
> [04.09.09 11:20:23] Bert: yes, and move to summer release, and  
> assign to yourself, all in one go
> [04.09.09 11:20:57] Bert: that's all in the "resolve" page
> [04.09.09 11:24:36] Scott: In terms of the "proess" page, however,  
> I'd say that Sq-267 might count as still being in the Sifting phase,  
> because people have not commented on it; it's a ui change that adds  
> more items to the precious supplies-bin real-estate.   And if we do  
> decide we want it, the choice of where the two new items should  
> appear in the supplies bin will have to be made (my fileout puts  
> them at the end).  Is this all really stuff that should count as  
> "resolved"?
> [04.09.09 11:27:38] Bert: it's resolved in a way. whether we like it  
> or not is up for discussion. the discussion starts by marking it  
> resolved, it's easier to discuss code. you should put exactly what  
> you just wrote into the resolve comment. it feels odd I agree, but  
> we may just say yep, that's good enough, ship it.
> [04.09.09 11:28:07] Scott: okay -- thanks.
>
> And since this affects the UI in a way, how do we get someone of the  
> edu team to look at it? They rarely (if ever) comment on issues.  
> It's also not part of the workflow you proposed.


Resolved means "I've completed my coding".

Then comes code review / testing.   If there's any further discussion,  
the issue is "reopened".

If we decide we don't want it, the issue is "rejected".

If we want the ed team to comment, we reopen, attach a screenshot, and  
send a note to the ed team.

The ed team also has the option to comment on betas, which we'll have  
monthly, so there's plenty of time to make changes.

Does this help?

Tim