Just watched the screen cast on Taxonomy, very useful feature. One area I can see applying that is changing versions label to milestones but this would effect all projects in the system. A nice feature would be the ability to change taxonomy per project. So if I have a project that is for managing a marketing project I would not need Versions but Milestones would be more appropriate for that project, and if I had a project in the same system for managing software bugs versions would be needed.

Taxonomy per Project is on hold for the time being.

The issues are around added complexity and management, and finding a clean way to implement this.  Typically, you would want to use a single taxonomy across a group of projects, or "all, except project this project", etc.

I suspect we will implement this in Q1 2010.

A. Issue Tracking

Milestone improvements are due in Q4 as well as nested Versions support.

As for Requirements: there is an Issue Type for this purpose.  Suggested process:  Add "Requirement" issue types and then add sub-isues below it that reflect the actual work items required to satisfy the Requirement.  Since top level issues cannot be closed until all sub-issues are closed, you have some degree of control over knowing that you can only close a Requirement once all work items below (sub-issues) have been closed. 

B. Issue Tracking

Have a look at the Portal Mode Webcast: http://countersoft.com/webcasts/gemini/HelpDeskMode/HelpDeskMode.html

We also have an "add-on" product for this scenario coming out in Q4. More on this nearer the time.

Do you have any updates on this Taxonomy issue?

http://www.countersoft.com/downloads/whitepapers/implementinganissuemanagementplatform.pdf

After reading your "Implementing an Enterprise Wide Issue Management Platform" white paper and paying special attention to the areas that talk about adopting relevant terminology it has dawned on me that the limitations of Gemini's Taxonomy hinder it's ability to be an enterprise wide issue management system.

If I cannot change the taxonomy per project or at least project group then it is not enterprise ready.  I am currently tasked with implementing Gemini throughout our entire organization, the operations and marketing departments have to see the same taxonomy as the IT department and software developers.

If I change the Versions and Components labels for the marketing team to something more suitable then it also effects the IT and Software developers where those terms are relevant. This is going against what your white paper is talking about with using familiar terminology to assist with adoption. I would have to maintain multiple instances of Gemini in order to implement the different taxonomy requirements per department.

One challenge I have here is that users that are not part of our IT department are used to using other project management systems that allow them to specify Milestones (rather than version) and I noticed that Gemini has Milestones as part of a version. This makes implementing Gemini for non technical projects somewhat like putting a square peg in a round hole. My users will struggle with the odd implementation of milestones being part of a version.

So far I think Gemini is a powerful issue management system and well worth the price but the limitations with the taxonomy hinder it from being an enterprise wide solution. This makes my job of gaining adoption from all departments in our company as well as external clients allot more difficult.

Per Project Taxonomy

Yes, it would be ideal to control taxonomy at the project level.

What would happen when users typically want to view issues from multiple projects where each project has different taxonomy?  Will the Issues Grid and Issues Filter label columns and boxes as  "Component" or "Module"? 

This is the only reason why we have held back from rolling out per project taxonomy.. 

We have seen many successful implementations where external participants and different internal departments all work using the same taxonomy -- one common language so to speak.  We are not talking about smallish 10 or 20 users roll-outs, we are talking about 100+ user roll-outs involving different user profiles and organizations (enterprise wide solution).

Milestones

Only Project Admins should be setting Milestones under Versions.  This is the way we do it and hence "regular" users should not even concern themselves with milestones as the Project Lead\Manager\Admin controls milestones. 

The primary purpose of Gemini is to track issues and not milestones.