[etoys-dev] jira re-arrangement

Timothy Falconer timothy at squeakland.org
Fri Aug 21 23:36:41 EDT 2009


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

2. "desirable" = normal priority

3. "possible" = eventual priority

4. "desirable but complex or risky" = optional priority

5. "published!" = closed

6. "ready for testing" = resolved

7. "internationalization" = moved in with the rest (in 4.1 release)

8. "pango" =  moved in with the rest (in 4.1 release)

9. "dormant, residual, historical"  = optional priority in someday  
release

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)


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.

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.

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".)


So if you're wondering:

* what should I test?    Click "Resolved" under Project Summary o see  
a list of resolved issues.  These need testing.

Add a comment saying, "works for me" and then put the change to the  
update stream and click "Closed" (aka Published)

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.


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.

Tim








More information about the etoys-dev mailing list