[etoys-dev] jira re-arrangement

[Timothy Falconer]

On Aug 22, 2009, at 1:08 AM, Yoshiki Ohshima wrote:

> At Fri, 21 Aug 2009 23:36:41 -0400,
> Timothy Falconer wrote:
>>
>> Hi all,
>>
>> Made some changes to JIRA to help with release planning.   Please
>> review this JIRA glossary first:
>>
>> http://confluence.immuexa.com/display/sq/Process
>>
>> If the terms don't seem to make sense, then return to the glossary  
>> and
>> read them again and again.
>>
>> I've used JIRA with a wide variety of software teams over the last
>> five years, so please rely upon my experience until it becomes more
>> familiar.
>>
>> JIRA is used by Apache and many other large open-source projects ...
>> there's truly a "there" there, but only if you relax and use it as it
>> was designed to be used.
>>
>>
>> The changes:
>>
>> 1. "must-have" = critical priority
>
>  We still have a "Blocker" item.  Is it merged to "Critical"?

Blockers should be very infrequent.  Our definition of Blocker is  
"something that's preventing someone from getting work done", or  
"something that will block a release".

Remember also that these priorities are being used by the education  
and business teams, and by other software groups on the same server.

The ongoing priority is primarily for issues in the "ongoing"  
release . . . these are used primarily for time logging (regular  
chats, etc, publicity, etc).

Stuff too general to make their own issue.

>> 2. "desirable" = normal priority
>>
>> 3. "possible" = eventual priority
>>
>> 4. "desirable but complex or risky" = optional priority
>
>  Otherwise these new priorities are better.  "Ongoing" is going  
> away, too?

BTW, these are the priorities from last April :)

>> 10. two big versions ... "etoys 4.0 - summer 2009" and "etoys 4.1 -
>> winter 2010"   (summers will be even numbered, winters will be odd
>> numbered)
>
>  Still, the nature of our project (relatively stable working system
> with very scarse man power) seems that we usually don't
> have too many blockers and critical ones (we shouldn't).  So if timely
> release is important, "must-have" for a release wouldn't make it
> really "must-have".

Priorities serve two purposes ... sorting and alerting . . . I see a  
"blocker" and it's the first thing I talk about, every time.    
Otherwise they're just a way to work down the list.


>> The reason for all of this is so that we can actually look at the
>> roadmap and see where we are.  Things were too fragmented.  They were
>> going against the way JIRA works.
>
>  Ok.
>
>> So now, there's three release bins showing on the roadmap:
>>
>> a. review ... all new stuff goes here and gets moved elsewhere after
>> discussion
>>
>> b. etoys 4.0 ... current release
>>
>> c. biz/ed ... these are the non-Etoys items that the business and
>> education teams must do
>>
>> There will always be these three at the top of the release road
>> map ... click "all versions" to see etoys 4.1, etc.
>
>  Much better.  Saner prioritizing would be even better.

Suggest away, in comments, or simply change priorities yourself.    
Like a wiki, simply changing something is saying "I think this should  
be changed to this".

The current priorities come from TRAC and Scott, for the most part.

>> Anyway, I hope this makes things clearer.  As you continue to use
>> JIRA, you'll see that many tools exist that require this
>> functionality.  (Try "Find Issues", for example, then click "New".)
>
>  Some JIRA questions:
>
>  - Can I search for all comments by a registered user (or all issues
>    commented by the user)?

Hmm... interesting, you can search comments, but you search almost  
everything else :)

Maybe the new JIRA upgrade will have this.

>  - Can I see the list of "all activities" (all changes on any item)
>    in last 24 hours?

 From the "browse" page, click "Updated recently" ... it's not the  
last 24 hours, but it lets you scan the same way.


>> Add a comment saying, "works for me" and then put the change to the
>> update stream and click "Closed" (aka Published)
>
>  Hmm, putting the change to the update stream is so far limited to
> certain users.  (And "works for me" just by somebody often is not the
> right reason to "Close" an item.)

I think my initial process page said that software team members verify  
and push to the stream (#13):

http://confluence.immuexa.com/display/sq/Process

Priorities and code review are the primary function of the software  
team.

Is this sufficient?

>> Would other words be more clear?   Perhaps to some.   In my opinion,
>> let's all try to learn these five states (scheduled, in progress,
>> resolved, closed) and five priorities (blocker, critical, normal,
>> eventual, optional).   They work.
>
>  Ok.  As long as issues are not going away, we can surely work with
> it and make more changes if necessary.
>
>> Also, remember ... the best view is "road map" ... it sorts by
>> priority into releases.   It also has a nifty green & red progress  
>> bar
>> that motivates.
>>
>> Now, I'm going back into my post-Squeakfest cave for a while ... in
>> the next week or so, please help move things in "review" or "etoys
>> 4.0" that we can't do easily in the next few weeks to "etoys 4.1"
>>
>> Our overall goal is to have Etoys 4.0 be all green in the roadmap.
>> Another goal is to have zero issues in "review".
>>
>> Sorry for the draconian changes, but I couldn't get my finger on the
>> pulse of the release the way it was.   This is a better way to work.
>
>  Thanks!
>
> -- Yoshiki
> _______________________________________________
> etoys-dev mailing list
> etoys-dev at squeakland.org
> http://lists.squeakland.org/mailman/listinfo/etoys-dev