Organize the developer docs into a "Pilcrow for Developers" book.

The audience for this is developers looking to make changes to Pilcrow, either on the server, on the included client, or via its data model. Most of the material here is drawn from existing documents, but organized somewhat more coherently.

I've left some space for client documentation, though no such documents exist yet.

1 files changed, 13 insertions, 0 deletions

diff --git a/docs/developer/design-guidance.md b/docs/developer/design-guidance.md
new file mode 100644
index 0000000..28269dd
--- /dev/null
+++ b/docs/developer/design-guidance.md
@@ -0,0 +1,13 @@
+# Design guidance
+
+Pilcrow's design is discovered and not planned. Do not take existing design as doctrine; instead, change the design to accommodate new needs and past lessons.
+
+When making decisions about this design, consider the following:
+
+- The target audience for this service is individuals running servers for their local communities. The archtecture is deliberately designed to be tractable and easy to understand, and to be deployable on as wide a range of internet-connected systems as is feasible.
+
+- While we don't have a specific goal for scale, think tens to hundreds of people, not tens to hundreds of thousands of people.
+
+- The modern browser is a surprisingly capable and complex platform in its own right. It may not be the only client platform we expect people to use in the long term, but it's a solid foundation for a client today.
+
+- The one thing it has to do, pretty much no matter what, is deliver messages. When that's not possible, the only responsible way to deal with the situation is to inform users that the operation they're asking for will not be completed.