diff --git a/docs/ant2/requested-features.txt b/docs/ant2/requested-features.txt
new file mode 100644
index 000000000..e6518e423
--- /dev/null
+++ b/docs/ant2/requested-features.txt
@@ -0,0 +1,116 @@
+Brainstormed and unordered list of requested features of Ant2:
+
+* namespace support so different concerns can occupy different namespaces
+  from ant (thus SAX2/JAXP1.1)
+
+* Java2
+
+* The ability for GUI/IDE tools to integrate easily with object model
+  without reinventing the wheel and writing their own parser (which
+  antidote was forced to do). Two suggested solutions were allowing GUI
+  developers to extend object model (ie GUITask extends Task) or to have
+  Task as interface (ie GUITask implements Task). This way the GUI tasks
+  could be W3C DOM Elements, have property vetoers/listeners etc.
+
+* Fully interpreted at runtime. This almost requires some form of
+  abstraction/proxy that stands in place of tasks till it is
+  interpreted.  This can be hashtables/simple dom-like model/whatever
+
+* provide utility classes to aid in building tasks. ie like up-to-date
+  functionality abstracted
+
+* make ant-call a low cost operations so it can certain
+  optional/template-like operations
+
+* allow facilities to build projects from multiple sources. ie CSS+xml
+  or XSLT+ XML or database or from inside jars or normal build.xmls
+  etc.
+
+* remove magic properties if at all humanly possible
+
+* make all tasks consistent and remove all deprecated methods
+
+* move to a system that allows docs to be generated - doc snippets
+  should be included with the tasks they document.
+
+* allow documentation to be stored in .tsk jars
+
+* allow tasks to be loaded from jars. tasks should be indicated by
+  either xml file in TSK-INF/taskdefs.xml or manifest file.
+
+* remove as much dependency on native scripts as possible.
+
+* clean object model (ie Project/Target/Task)
+
+* good event model to integrate well with IDE/GUI/whatever
+
+* better scripting/notification support so the hooks are available to
+  send notifications at certain times.
+
+* allow all datatypes to be defined anywhere
+
+* make usage of particular filters/filtersets explicit in copy tasks
+
+* make facade tasks for things like javac (JikesImpl, ModernImpl etc)
+
+* seperate tasks into .tsk jars somehow. (Probably via function - ie
+  java tasks, file tasks, ejb tasks).
+
+* unify multiple similar tasks to use similar forms (ie all the javacc
+  type tools)
+
+* support for numerous frontends - from command line over GUI to servlets
+
+* make properties fully dynamic, i.e. allow their value to be reassigned
+
+Now there is a bunch of "controvertial" points. By controvertial I mean not
+everyone agrees or else there has not been enough comments to to judge
+reception
+
+* unify the namespace of all data types (ie properties + filesets +
+  patternset + filtersets).
+
+* provide datatypes through property tag and remove need for seperate free
+  standing entities. ie
+  <property name="foo">
+    <fileset dir="blah">
+     <include name="*/**.java" />
+    </fileset>
+  </property>
+
+
+* make it possible to reuse taskengine for other things. ie
+  Installshield type app, my cron-server and other task based
+  operations. Currently no committer other than me has expressed
+  positive or negative thoughts about this
+
+* make separate build files easy (ala AntFarm) and importing different
+  projects a breeze
+
+* create the concept of workspace so that projects can be built in a
+  DAG and thus enable projects like catalina/tomcat to have an easy
+  build process. It also helps CJAN to a lesser degree and would
+  partially solve the JARs in CVS thing.
+
+* provide support for CJAN
+
+* provide support for non-hardwired (ie loadable) converters.
+
+* provide support for non-hardwired (ie loadable) datatypes.
+
+* generate docs by anakia/XSLT
+
+* provide support for user defined task configurations - i.e. give
+  users the ability to specify a default value for attributes (always
+  use debug="true" in <javac> unless something else has been
+  specified). Could be a CSS like language, could be a <taskconfig>
+  element ...
+
+* support more control over the properties that are going to be passed
+  to subprojects (modules)
+
+* keep build file syntax as compatible to Ant1 as possible -
+  i.e. don't break something just because we can.
+
+* keep the interface for Tasks as similar to the one of Ant1 as
+  possible - i.e. don't break something just because we can.
\ No newline at end of file