[etoys-dev] jira re-arrangement

[Yoshiki Ohshima]

At Mon, 24 Aug 2009 17:56:58 -0400,
Timothy Falconer wrote:
> 
> >> 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".

  Blockers are very infrequent, yes, and that is the argument that
maybe we don't need it (or we don't have to use it).

  The only one Blocker we have now is not "something that's preventing
someone from getting work done".  And if it is "something that will
block a release", what is the difference it has from "must-have"?

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

  Ah, other software groups...  So we may just avoid it, if we want.

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

  I don't understand it but sounds like I can just ignore it.

> >  Otherwise these new priorities are better.  "Ongoing" is going  
> > away, too?
> 
> BTW, these are the priorities from last April :)

  Right.  The new road map is better.

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

  I again don't understand it well...  Isn't sorting for alerting?
(But never mind.  There is always different channels to talk about the
importance of issues anyway.)

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

  At least the release road map part is simplified so I think I
understand it better.

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

  Ok.

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

  Ah, good, thanks.  This is useful.

> >> 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?

  The text in the "jira re-arrangement" email was written to the
community, right?

  Surely reviews and reports that say the code works for some
community member is useful and important, but it shouldn't be
automatically tied to "Closed" and "Published" status, I thought.

-- Yoshiki