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 - ReopenedI 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" ([email protected]) 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 "[email protected]", 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 "[EMAIL PROTECTED]" 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.
Pier
smime.p7s
Description: S/MIME cryptographic signature
