Prior to Drupal PM 7.x-2.x ( i.e. in Storm and Drupal PM 7.x-1.x) there were only Tickets and Task. The issue was addressed in - #364252: What's the difference between a task and a ticket? to an extend.

After studying various existing project management software we came to a conclusion that basically there is no difference between Task/Ticket/Issue/Bug from a systematic point of view. The difference is more cultural and the workflow that the user follows. 

7.x-2.x architecture received an overhaul to support some more scenario (read as culture and workflow). It is trying to be less opinionated how the user should use it.

  • If there exists a different workflow for Task, Ticket, Issue and Bug, then it makes sense creating a content type for each of them. In this scenario PM Ticket and PM Task can be reused. PM Permission module was introduced for facilitating this. It is now possible to use Drupal PM specific permissions (view XXX if assigned, edit XXX if belonging to same organization, etc...) on newly created custom entities.
     
  • In case there is no difference in workflow for tickets/task/Bug/Issue then it doesn't make sense to use different entity. "tickets/task/Bug/Issue" would serve as merely a label for a particular issue. 

Help me choose between them Please!

Following Q&A will help you decide when to use different entity like PM Task/PM Ticket or when to use PM Issue.

When to use different entities (i.e. PM Task, PM Ticket, custom, etc... )

  1. Do you want your task and ticket to have different permissions associated with it?
  2. Do you want to use different workflow for your task and ticket?
  3. Does your task and ticket have different set of fields attached to them?
  4. Are you task and ticket structure rigid and they don't migrate to each other? (i.e. task doesn't become ticket and ticket doesn't become task later)

If the answer to all the above questions is a "yes", then you would have no choice but use different entites for task and ticket. Thus you can use (but not limited to) PM Task and PM Ticket. Tweak the entity relationship between each to suite your workflow.

When to use singe entity (i.e. PM Issue)

  1. If there is no difference in permission for task/ticket
  2. If they all share same fields.
  3. If they need to change from one form to another, for example a ticket becomes a task later.

If all the above conditions are satisfied then it make sense to use single entity, like PM Issue.

How should i set up the references/hierarchy?

Again this depends upon you. Just by removing the restrictions or adding them in the respective entity reference field settings you can change the heirarchy. Thus following hierarchies (not limited to) is totaly achievable and usable, even though Drupal PM by default follows the one mentioned in Entity Realtionship Diagram section of the respective releases.

  • Organization -> Project -> Ticket -> Task
  • Organization -> Project -> Task & Organization -> Project -> Ticket
  • Organization -> Project -> Issue
  • Organization -> Project -> Task -> Sub-Task (a custom entity)
  • Organization -> Project -> Bug (a custom entity) -> Task, etc...

Examples

Even though Drupal PM doesn't have bias on emphasizing on a particular workflow, the following examples can help users getting started.
 

Example 1: Using different Entities.

Consider a scenario where we have a Client, a Project Manager, a Developer and a Support.

  1. Client should be able to communicate needs while the project is ongoing. But he should not be able to directly influence the Developer.
  2. The Project Manager decides what a Developer should do.
  3. The Support person should be able to view concern's raised by the Client and respond if he could or notify the Project Manager otherwise.

Given the above scenario lets define task and ticket as follow.

  • Ticket
    An question/feature request/bug/support request reported by QA team or client. Lets use PM Ticket for this.
  • Task
    A discrete unit of work an assignee needs to compete. This is usually created by a Project Manager. A Task can be created as a response to ticket or from Project specifications. Usually clients have no access or limited access to task. Lets use PM Task for this.

Set up permission in such a way that Tickets are accessible to Support, Project Manager and Client. Whereas Tasks are accessible to Project Manager and Developer only.

Example 2: Using Single entity

Consider one of the following scenario

  1. You are the only person using Drupal PM and all you need is just an entity to hold title and description.
  2. The whole team has a high level of trust and project process is visible to everybody using the software ( as in Drupal.Org ). 

In the above cases we can just use a single entity as follows,

  • Issue
    Every new question/feature/bug/support/task are created as Issues first. Later it can be categorized as Ticket/Bug/Task/Story or whatever label feels appropriate according to the situation.