[etoys-dev] jira re-arrangement

kharness at illinois.edu kharness at illinois.edu
Fri Sep 4 10:04:13 EDT 2009

You said: "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."

I agree. It is a very good idea to have people in the edu team see these issues sooner rather than later in the process. Many times I have felt like I wanted to know more about what I am reading in the lists and yet I do not have the technical knowledge to understand what is going on and I don't wish to slow down what is already a complex process by asking for explanations that may be painfully basic and obvious to developers. 

I would be very glad to try new changes and comment if someone will teach me how to join the stream of changes that may or may not be included in a release. I am teaching at an elementary school again this year and have a 100 students who will happily join me in experimenting with new ideas every week. 

---- Original message ----
>Date: Fri, 4 Sep 2009 11:42:37 +0200
>From: Bert Freudenberg <bert at freudenbergs.de>  
>Subject: Re: [etoys-dev] jira re-arrangement  
>To: etoys dev <etoys-dev at squeakland.org>
>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.
>do we want to always resolve when there is a change set? See chat log  
>[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.
>- Bert -
>etoys-dev mailing list
>etoys-dev at squeakland.org

More information about the etoys-dev mailing list