Per-"software project" oriented queue or per-"service"?

I have browsed unuseful much on RT docs & resources: wiki, FAQ etc…

in the RT book i have read that the RT logic and philosophy discourages
creation of queues
that have short lifetime due “users, groups, and queues” are thought to
be stable during time.

I need to manage bug tracking for different software projects, more or
less in the same way. Each software project has a defined lifetime (some
month, in average, and then is “closed”) and each of them has a
different development team, verification team, QA team etc…

I see two possibilities:

  1. define one queue “sw-bugs” and manage different project apportionment
    using a Custom Fields named “Project” with values
    “Project1”,“Project2”,“Project3”… ; but how to manager membership in
    this way? Is it a problem if such values changes oftern during time?
  2. use one different queue for each sw project: this seems to be much
    reasonable , but all configuration examples that I see about RT seems to
    not to be a best practice in general: does it have some side effect to
    have a constantly growing set of queues in the RT instance?

what does it seems to be a best practice of the two above ?

Thank you for you help!

Fabrizio Sebastiani
NERGAL srl - Via B. Bardanzellu, 8 - 00155 Roma - Italy
web : http://www.nergal.it
office phone : +39-06-40801173
office fax : +39-06-40801283
mobile : +39-328-3139798
e-mail : fabrizio.sebastiani@nergal.it

Fabrizio,

Why not a third option? Create a Queue for each SW project, then when the
project is over, just rename the Queue to indicate it now serves as an
“Application Support” Queue to handle future bugs, enhancements and
Customization requests
? The Queue stays alive and ALL history for all kinds
of work done for that software is in one place. That would be especially
helpful if a request for a customization comes along and the engineer wants
to know why certain tasks were designed/coded a particular way, the
email/comments history would be helpful.

Just a thought.

Kenn
LBNLOn Thu, Feb 10, 2011 at 2:51 AM, Fabrizio Sebastiani sebastiani@nergal.itwrote:

I have browsed unuseful much on RT docs & resources: wiki, FAQ etc…

in the RT book i have read that the RT logic and philosophy discourages
creation of queues
that have short lifetime due “users, groups, and queues” are thought to be
stable during time.

I need to manage bug tracking for different software projects, more or less
in the same way. Each software project has a defined lifetime (some month,
in average, and then is “closed”) and each of them has a different
development team, verification team, QA team etc…

I see two possibilities:

  1. define one queue “sw-bugs” and manage different project apportionment
    using a Custom Fields named “Project” with values
    “Project1”,“Project2”,“Project3”… ; but how to manager membership in this
    way? Is it a problem if such values changes oftern during time?
  2. use one different queue for each sw project: this seems to be much
    reasonable , but all configuration examples that I see about RT seems to not
    to be a best practice in general: does it have some side effect to have a
    constantly growing set of queues in the RT instance?

what does it seems to be a best practice of the two above ?

Thank you for you help!


Fabrizio Sebastiani
NERGAL srl - Via B. Bardanzellu, 8 - 00155 Roma - Italy
web : http://www.nergal.it
office phone : +39-06-40801173
office fax : +39-06-40801283
mobile : +39-328-3139798
e-mail : fabrizio.sebastiani@nergal.it