3 files changed, 0 insertions, 86 deletions
diff --git a/rt/docs/design_docs/basic-definitions.txt b/rt/docs/design_docs/basic-definitions.txt
deleted file mode 100644
index 23d2c5748..000000000
--- a/rt/docs/design_docs/basic-definitions.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-(todo ... basically, those are untouched from 1.0)
-Ticket
-Queue
-(...more?)
-
-Requestor
-
-  (...definition of a requestor .. blahblah)
-
-  I'm often doing a distinction between "Internal Requestors" and "External
-  Requestors" (see below).  The system doesn't make any difference between
-  requestors, but the distinction might be useful to discuss usage patterns,
-  templates and configurations.
-
-
-External Requestor
-
-  Might be a customer or a potential customer.  The External Requestor
-  should be treated as a VIP.  (S)he shouldn't need to see too much of RT.
-  The support (s)he gets should be as personal as possible.  The external
-  requestor might eventually get access to the Web UI, but only to track
-  her/his own requests.  If you're not planning to use RT for handling
-  external customers, all your requestors are probably "Internal
-  Requestors".
-
-
-Watcher
-
-  Somebody that are "subscribing" to a queue or a ticket (or something
-  differently).  Basicly, somebody watching a queue or a ticket should get
-  all updates by email.  A requestor is a (special) watcher.
-
-
-Regular Watcher
-
-  People within the same organization, people that have read access to whole
-  queues.
-
-  I consider "Regular Watchers" as well as "Internal Requestors" as more
-  robust and capable human beeings than the fragile customers.  We don't
-  mind letting them get entagled with RT, and we let them access the Web UI.
-  They can live with beeing just the Cc or Bcc at an email.
-
-
-Internal Requestor
-
-  An Internal Requestor is usually internal to the company.  He might be 1st
-  line support sending matters to tech support or similar. Might be an
-  internal employee sending matters to tech support (or even 1st line
-  support if he's not sure where to send matters).  It might also be that
-  "ordinary" requestors actually might be treated as intelligent human
-  beeings rather than VIPs, i.e. in open source projects ... we'll still
-  call them "Internal Requestors" as they don't need the special VIP
-  treatment.
diff --git a/rt/docs/design_docs/local_hacking b/rt/docs/design_docs/local_hacking
deleted file mode 100644
index c06d1126d..000000000
--- a/rt/docs/design_docs/local_hacking
+++ /dev/null
@@ -1,32 +0,0 @@
-To facilitate local hacking, RT needs a mechanism to allow site administrators
-to easily add HTML templates for the web ui and to replace sections
-of code in RT's core modules _without_ having to modify those modules
-
-We'll use several methods to achieve this goal.
-
-	Webui
-		HTML::Mason allows users to create multiple
-component hierarchies.  RT should ship with a local component root
-defined and available. This root should be configured as the "primary"
-component root.
-
-
-	Core modules
-
-	This gets a bit trickier. we want to allow people to trivially
-subclass core modules and to use those subclasses throughout the code.
-
-The way we're going to handle this is by setting up a number of subroutines
-in config.pm that look something like this:
-
-sub NewTicketObj {
-	eval "require $TicketClass";
-	my $object = new $TicketClass;
-	return ($object);
-}
-
-# This variable is used for ref type checking
-$TicketClass = "RT::Ticket";
-
-we could use an eval around the require and thus completely avoid specifying
-the object in two places. which feels like a win. but i'm worried about perf.
diff --git a/rt/docs/rt.gif b/rt/docs/rt.gif
deleted file mode 100755
index 693b06238..000000000
--- a/rt/docs/rt.gif
+++ /dev/null