--- a/pyforge/docs/faq.rst
+++ b/pyforge/docs/faq.rst
@@ -1,5 +1,5 @@
Why not improve existing tools like Trac, Redmine or Bugzilla?
----------------------------------------------------------------
+---------------------------------------------------------------------
One word. Scalability.
@@ -7,18 +7,47 @@
Ok, three words: Scalability, Performance, and Flexibility
-Seriously though, we didn't think that any of the existing systems have actually hit the right usibility targets, and we knew that it would be a **lot** of work to get any of them to scale up to the level we needed.
+Seriously though, we didn't think that any of the existing systems have
+actually hit the right usability, scalability, or flexibility targets that
+we needed to hit, and we knew that it would be a **lot** of work to get
+any of them to do what we needed.
-But we knew e-mail integration was going to be a big deal to our forge, so we did take a long look at Roundup, which is a very well designed system build from the ground up around the idea of e-mail integration.
+But we knew e-mail integration was going to be a big deal to our forge,
+so we did take a long look at Roundup, which is a very well designed
+system build from the ground up around the idea of e-mail integration.
If you were so inspired by Roundup, why not just use it?
----------------------------------------------------------------
+---------------------------------------------------------------------
-We liked the flexible schema system provided by Roundup's HyperTable layer, but thought that native MongoDB bindings were both cleaner, faster, and ultimately more powerful. Sure we sacrifice the flexibility of Roundup's backend, but our main goal is to make usable, high performance system, not to maximize the number of backend storages systems supported.
+We liked the flexible schema system provided by Roundup's HyperTable layer,
+but thought that native MongoDB bindings were both cleaner, faster, and
+ultimately more powerful.
+
+Sure we sacrifice the flexibility of Roundup's
+backend, but our main goal is to make usable, high performance system,
+not to maximize the number of backend storages systems supported.
+
+Why create all the apps as plugins?
+---------------------------------------------------------------------
+
+We know that some projects are going to want more locked down
+access controls in their bug trackers, or more workflow based
+processes. These things are inevitable, and we really do want
+to support them, but at the same time they are going to conflict
+with the way many other projects want to work.
+
+Building a plugin system, and standard integration points
+makes it possible to serve everybody in one way or another.
+
+Why not just allow web-based extensions?
+---------------------------------------------------------------------
+
+We talked about this quite a bit, and decided that we could write local
+native plugins more quickly and easily, and that we could build a
+local app plugin that proxied out to an external webapp, and that
+we could provide a lot more flexibility by allowing custom
+external webapp proxies -- which brought us right back to local
+plugins.
----------------------------------------------------------------
-
----------------------------------------------------------------
-
----------------------------------------------------------------+---------------------------------------------------------------------