Switch to unified view

a/pyforge/docs/faq.rst b/pyforge/docs/faq.rst
1
Why not improve existing tools like Trac, Redmine or Bugzilla? 
1
Why not improve existing tools like Trac, Redmine or Bugzilla? 
2
---------------------------------------------------------------
2
---------------------------------------------------------------------
3
3
4
One word.  Scalability. 
4
One word.  Scalability. 
5
5
6
Ok, two words.  Scalability and Performance
6
Ok, two words.  Scalability and Performance
7
7
8
Ok, three words:  Scalability, Performance, and Flexibility
8
Ok, three words:  Scalability, Performance, and Flexibility
9
9
10
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.
10
Seriously though, we didn't think that any of the existing systems have 
11
actually hit the right usability, scalability, or flexibility targets that 
12
we needed to hit, and we knew that it would be a **lot** of work to get 
13
any of them to do what we needed.
11
14
12
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.
15
But we knew e-mail integration was going to be a big deal to our forge, 
16
so we did take a long look at Roundup, which is a very well designed 
17
system build from the ground up around the idea of e-mail integration.
13
18
14
If you were so inspired by Roundup, why not just use it?
19
If you were so inspired by Roundup, why not just use it?
15
---------------------------------------------------------------
20
---------------------------------------------------------------------
16
21
17
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.
22
We liked the flexible schema system provided by Roundup's HyperTable layer, 
23
but thought that native MongoDB bindings were both cleaner, faster, and 
24
ultimately more powerful.  
25
26
Sure we sacrifice the flexibility of Roundup's 
27
backend, but our main goal is to make usable, high performance system, 
28
not to maximize the number of backend storages systems supported.
29
30
Why create all the apps as plugins? 
31
---------------------------------------------------------------------
32
33
We know that some projects are going to want more locked down
34
access controls in their bug trackers, or more workflow based 
35
processes.  These things are inevitable, and we really do want
36
to support them, but at the same time they are going to conflict
37
with the way many other projects want to work.   
38
39
Building a plugin system, and standard integration points
40
makes it possible to serve everybody in one way or another. 
41
42
Why not just allow web-based extensions? 
43
---------------------------------------------------------------------
44
45
We talked about this quite a bit, and decided that we could write local
46
native plugins more quickly and easily, and that we could build a 
47
local app plugin that proxied out to an external webapp, and that
48
we could provide a lot more flexibility by allowing custom
49
external webapp proxies -- which brought us right back to local 
50
plugins. 
18
51
19
52
20
21
22
23
24
---------------------------------------------------------------
53
---------------------------------------------------------------------