Switch to side-by-side view

--- a/Allura/docs/faq.rst
+++ b/Allura/docs/faq.rst
@@ -1,54 +1,51 @@
-Why not improve existing tools like Trac, Redmine or Bugzilla? 
+Why not improve existing tools like Trac, Redmine or Bugzilla?
 ---------------------------------------------------------------------
 
-One word.  Scalability. 
+One word.  Scalability.
 
 Ok, two words.  Scalability and Performance
 
 Ok, three words:  Scalability, Performance, and Flexibility
 
-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 
+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 
+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.  
+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, 
+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 
+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.   
+with the way many other projects want to work.
 
-Building a plugin (tool in Allura terms) system, and standard 
-integration points makes it possible to serve everybody in one 
-way or another. 
+Building a plugin (tool in Allura terms) system, and standard
+integration points makes it possible to serve everybody in one
+way or another.
 
-Why not just allow web-based extensions? 
+Why not just allow web-based extensions?
 ---------------------------------------------------------------------
 
 We talked about this quite a bit, and decided that we could write local
 native tools more quickly and easily, and that we could build a
 local app tool 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 
+external webapp proxies -- which brought us right back to local
 tools.
-
-
----------------------------------------------------------------------