For 2.0, those Linking actions should be supported:

1. DependentOn; TobiX-style.

 BASE is dependent on TARGET.
 
 ...meaning that TARGET has to be resolved before BASE (really) is
 resolved.
 
 According to TobiX, those "weird action" makes sense:
 ...when the link and/or TARGET is created, the BASE might be stalled.
 Alternatively, this should be very trivial to request through the UIs.
 ...when the TARGET is resolved, BASE will be reopened if it's stalled.

 An alternative to those "weird actions" is to have some run-time logic that
 takes care of this; i.e. letting the search interface handle "please hide
 all requests with unresolved dependencies"
 
 TobiX will need to make dependency links into Bugzilla.

 Dependency links should be made when more work to BASE should be done
 after the TARGET is resolved and/or BASE can't be resolved before TARGET is
 resolved.

 Dependency links are often 1:1, but n:n links makes sense; one ticket can
 depend on several others, several tickets can depend on one ticket, etc.

 Loops don't make sense at all, but the system above won't break if it
 encounter loops.

 Dependency links is more for workflow than anything else.  When a new
 TARGET is created, some of the work might be passed over to another
 department/person ... but _not_ the responsibility for the communication
 with the external requestor.

2. MemberOf link (grouping)

 BASE is a member of TARGET.

 TobiX-style "weird actions":
 ...when TARGET is beeing replied to, all BASE requestors should get the
 reply.

 ...when TARGET is resolved, all BASE tickets should be resolved (unless
 they have other unresolved Dependencies/MemberOf links).

 ...when all BASEs to one TARGET are resolved, TARGET should be resolved.
 
 The alternative is to let the user choose "reply to all" and "resolve all"
 through the user interfaces.

 MemberOf should be used when BASE ticket states more or less the same as
 the TARGET ticket, and we do want to give a reply to all requestors, but we
 don't want to merge them (Individual tickets from individual external
 requestors should be respected as separate entities). If BASE tickets from
 more than one external requestor is linked to a TARGET ticket, we denote
 the TARGET ticket as a "Group ticket".  This is only a documentation
 definition, you won't find any references to "Group tickets" in the source.

 I think the proper etiquette should be to clearly state in a reply to a
 group ticket that the mail is going to several persons, and that the
 requestor should reply back if they feel their Ticket hasn't got the
 attention it deserves.  The user documentation should reflect this.

 MemberOf links can also be used to hand away the work flow. The person in
 charge of the TARGET ticket will also be in charge of the BASE tickets and
 the communication with the end user.

 If a work task needs to be splitted into two subtasks, MemberOf might also be
 used.

 1:n links makes more sense, but n:n can also work in some cases.
 The reply stuff might break seriously upon loops.  Recursement might be
 handy for splitting a work task into subtasks (making a hierarchical tree
 of the worktasks).


3. Merge (connecting)

 BASE is the same as TARGET.

 ...the system should somehow merge together transactions for both tickets.
 ...BASE should be more or less deleted, only the TARGET should apply.
 ...actions done toward BASE should be redirected to TARGET.

 I think MergeLinks should be used when two tickets accidentally has
 appeared twice in the system, and/or there is no reason to keep the two
 tickets separately.  It might be that it's the same requestor (i.e.
 clicking the "send" button twice in a web environment) or that we don't
 care much about giving the requestor individual follow-up (typically
 "internal" requestors, etc.)

 Based on user feedback, merged tickets will be displayed as the same ticket
within RT's user interfaces. but the original tickets' transactions will be
kept separated in the database. this may require some magic.
 
4. RefersTo / No Action link (linking)

 BASE is somewhat related to TARGET

 No special actions will be taken.
 
 Loops might maybe make sense

BASE and TARGET are usually Tickets within one RT instance, but it
might also point to external RT instances, other DB systems, etc.




In future revisions, it should be very easy to set up site-specific link action types.
We should also consider to include more linking actions in the box.

An example stolen from John Rouillard.  Eventually the [comments] should be
removed, and the text modified to fit the planned 2.0 link actions:

  ticket  problem
    1         can't connect to hosts with netscape
    2         ping is broken
    3         Can't send email: error no space on spool/mqueue
	  
  You have the above in the queue. You realize that DNS is down. Spawn
  a ticket
	  
    4         DNS is down

  mergelink 1 and 2 to it [I would rather say "make a MemberOf link _or_ a
  dependency link from 1 and 2 to 4" --TobiX] (if you choose to stall 1 and
  2 automatically feel free, its just a shell script change) [well, you
  might choose dependency instead of MemberOf --TobiX]. The person working
  on 3 has come to the conclusion that outgoing mail is backing up because
  of the DNS failure. She has cleared space by copying the mail queue to
  another disk, but can't really get email working till DNS is up. So she
  creates a Dependency linkon  ticket 4 stalling ticket 3.

  We finally get DNS working and resolve ticket 3. What happens?  Tickets 1
  and 2 are resolved and email is sent to requestors notifying them of the
  resolution [This is the default behaviour for 2.0 MemberOf-linked tickets.
  Remember that if we send Replies to "Group Tickets" (that is, the target
  of several "MemberOf" links) --TobiX]. Ticket 4 [should be 3? --TobiX] is
  reopened and the person working on it starts flushing the mail queue and
  the moved mailq by hand. 

