diff --git a/mozilla/webtools/bugzilla3/bugzilla3-design.txt b/mozilla/webtools/bugzilla3/bugzilla3-design.txt
new file mode 100644
index 00000000000..7ca96d4c833
--- /dev/null
+++ b/mozilla/webtools/bugzilla3/bugzilla3-design.txt
@@ -0,0 +1,96 @@
+Design and Architecture 
+
+Bugzilla 3 is being designed from the ground up using a Perl based
+technology that has been developed explicitly for the purpose of
+developing UI agnostic applications. This technology is called PLIF
+and will soon be available as an open source resource from
+mozilla.org. PLIF has been developed over the course of the last
+couple of months by 1 (talented?) developer. PLIF provides the
+structure necessary to facilitate the development of web, IRC, command
+line and other applications by combining not only a large collection
+of useful code, but a model in which to develop these applications. In
+addition to using PLIF, we will also be using COSES as the template
+language for providing an environment where the HTML/XUL/text/whatever
+is completely abstracted from the business logic of the
+application. We are aware that people often claim that their
+applications provide this, so we have worked hard to insure that this
+is a reality.
+
+We choose Perl for a few reasons. The first is that the current
+Bugzilla 2.x developers are primarily interested in Perl for
+developing web applications. Perl has many advantages over other
+technologies.  It's fast, stable, portable and easy to write. There
+are other languages such as Python and Java that are also popular and
+we hope that people will choose to use Bugzilla-3-compatible ideas as
+the basis for developing their own front end applications. Just
+because we have chosen Perl does not mean that we are adverse to
+seeing Bugzilla 3 implemented in multiple different environments, it
+is just we needed to make a decision and our first decision and
+priority is Perl. :-)
+
+We are not interested at this point in getting into language wars. We
+chose Perl because it is a widely used technology that has been proven
+to work in large scale systems. As stated above, we feel that
+designing a solid foundation will allow anyone to port the UI front
+end of Bugzilla to any other language. In fact, we are encouraging
+this.
+
+One goal of Bugzilla 3 is to be able to translate from a Bugzilla 2.x
+schema to a Bugzilla 3 schema. Given this requirement, the
+functionality within the 2.x schema will remain available in Bugzilla
+3's schema. For instance, the Milestone field in Bugzilla will become
+a generic field called "Milestone" in Bugzilla 3. The only primary
+differences between the two will be additional features that are
+required by Bugzilla 3 and a more thought out and normalized database
+and code design.
+
+
+Features 
+
+Bugzilla 3's initial goal is to have equal feature functionality to
+Bugzilla 2.x, because Bugzilla 2.x is the most used issue tracking
+system for OSS projects. While Bugzilla 2.x is a great step forward
+from other systems (like GNATS), it is still missing out on a good UI
+design, code design and database schema design. So, what we have done
+is start with the concepts in Bugzilla 2.x's database schema and
+identified areas where it can be improved through better design and
+additional database normalization. Since we are using a web
+application framework (PLIF) and back end technology (Perl), we will
+also kill the code and design problems inherent in Bugzilla with one
+stone.
+
+A major problem with Bugzilla 2.x is that it is implemented in such a
+fashion that security is not taken into consideration and this has
+resulted in being a catalyst for high profiles sites being hacked into
+(including apache.org). The fact of the matter is that Bugzilla was
+never meant to be used outside of Netscape and the code shows. When
+Mozilla.org was created, there was a great hurry to provide some sort
+of issue tracking system for people to use. Bugzilla was available
+internally at Netscape and there were people at Netscape that knew how
+to install and use it. To Mozilla.org's credit (and the contributors
+to the project), Bugzilla has grown quite a bit, the TCL/TK
+dependencies were removed, the code has been cleaned up quite a bit,
+bugs have been fixed and features added. The problem is that this has
+been done on top of a poorly designed base which is not only hard to
+setup and configure (the first thing you have to do is change the path
+to the Perl executable in each and every file!), but also hard to
+customize the look and feel of because much of the look and feel is
+hard coded in Perl code. It is time to start over with something new
+that is designed from the ground up to scale to other people's needs.
+
+
+Processes 
+
+There are some well defined process's within Bugzilla 2.x that we do
+appreciate. For example, the Anatomy of a Bugs Life is a terrific
+example of how the whole process of dealing with an issue should
+work. However, some people do not wish to use this model, and so
+duplicating these rules within Bugzilla 3 is not a priority. Instead,
+we instead to make everything customisable and generic. The point we
+are trying to convey is that we are encouraging the idea of taking the
+good pieces and dropping the bad.
+
+
+With apologies to the Scarab people [1].
+
+[1] http://scarab.tigris.org/scarab-design.html