cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Shall we switch to Jira?
Date Wed, 14 Sep 2005 21:15:40 GMT
On 14 Sep 2005, at 21:34, hepabolu wrote:

>> Ok, I imported the old stuff from BugZilla, and made a few tweaks:
> Thanks for all the work.

No problem... It took quite a long time to do the import, but after  
that I personally can move through Jira quite easily, having managed  
an instance at work for more than a year.

>> The workflow in use is a simplified one, there are only three  
>> statuses:
>> - Open
>> - Closed
>> - Reopened
>> I took out the "In Progress" and "Resolved" as I personally never   
>> found any use for it, and I wanted to show off the simples JIRA  
>> setup  possible, but they can be re-inserted at any time (actually  
>> if  someone has better workflow ideas, I'm all ears).
> Well, I'm not an experienced Bugzilla user, so I might have  
> overlooked this, but when working on a bug I felt the need to  
> "mark" the bug "in progress" to avoid others working on the same  
> bug without each other knowing. So, in that case I would propose to  
> add "in progress".
> Or what's the best practice for this?
> Do we want to differentiate between bugs closed because they were  
> fixed (Resolved) or simply because they have become redundant? If  
> not, I go for simplicity.

I started with a simplicistic approach, one that everyone can  
understand. Changing the workflow does not take much time, it is a  
simple management process. So, whatever the community feels  
appropriate, can be replicated over there.

The "In Progress" status might be interesting. I personally never  
used it, but I have to admit in our installation at work we all  
roughly know what everyone else is working on... Instead of using the  
"in progress" status, we tend to assign a bug to an individual.

So, when the bug is "Open" and assigned to the "Cocoon  
Developers" ( you know that noone is actively  
working on it (there might be a discussion open on the list, but  
that's pretty much it). Once someone starts working actively on a  
bug, it assigns it to himself, so that others not only know that it's  
"in progress" but also who is taking on the task of solving it.

We could even set it up that new bugs are "unassigned" and that the  
workflow for assigning a bug forces to have an assignee... It's  
entirely open for discussion.

>> Users:
>> ------
>> The project owner is "", and I'm the only  
>> member  of the cocoon-developers group for now. Who wants to have  
>> access for  testing?
> I can't say I'm an experienced tester, but I'd like to have a look.  
> Is that possible or should I then be part of the group first?

You can use user "cocoon-test" password "test" to take a peek at how  
normal users (not in the cocoon-developers group) would interface  
with the system (normally, they would have less permissions than  
developers, for instance, they can't administer the project).

I've just put your account "" in the "cocoon- 
developers" group, so that you can see what the project  
administration gives to you in terms of more options than a normal user.


View raw message