diff --git a/proposed/public-area-meta.md b/proposed/public-area-meta.md
new file mode 100644
index 0000000..7bbbc43
--- /dev/null
+++ b/proposed/public-area-meta.md
@@ -0,0 +1,66 @@
+# Public Area Meta Document
+
+## 1. Summary
+
+Separate server side code from publicly accessible assets. 
+
+## 2. Why Bother?
+
+The simplest and safest way to avoid access to arbitrary files and to restrict access only to specific files is to have
+a separate directory for public files. This approach has the advantage that it works independently of the web server
+used and requires no further configuration other than setting the document root.
+
+## 3. Scope
+
+### 3.1 Goals
+
+### 3.2 Non-Goals
+
+## 4. Approach
+
+On some shared hosts it might not be possible to move DocumentRoot to a directory of the webspace. Therefore, the public
+area must be optional. At the very least, there must be a way to put the public files in the webroot instead of in a
+separate directory.
+This has to be documented accordingly.
+
+## 5. Design Decisions
+
+* Introduce a config variable for the location of the public directory. The default value for updates is '/', for new
+  installations it is '/public/'.
+* Make the path available through `JPATH_PUBLIC`.
+* If the public directory gets changed, corresponding files and directories are moved:
+  * administrator/index.php
+  * api/index.php
+  * media/
+  * index.php
+  * .htaccess
+  * robots.txt
+
+> The moved files might need some adjustments.
+
+## 6. People
+
+### 6.1 Editor(s)
+
+* Niels Braczek, <nbraczek@bsds.de>
+
+### 6.2 Sponsors
+
+* N/A
+
+### 6.3 Contributors
+
+* N/A
+
+## 7. Votes
+
+* **Entrance Vote:** _(not yet taken)_
+* **Acceptance Vote:** _(not yet taken)_
+
+## 8. Relevant Links
+
+_**Note:** Order descending chronologically._
+
+## 9. Errata
+
+...
diff --git a/proposed/public-area.md b/proposed/public-area.md
new file mode 100644
index 0000000..99dac5c
--- /dev/null
+++ b/proposed/public-area.md
@@ -0,0 +1,45 @@
+# \<Subject>
+
+This document describes ...
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC 2119][].
+
+[RFC 2119]: http://tools.ietf.org/html/rfc2119
+
+### References
+
+- [RFC 2119][]: Key words for use in RFCs to Indicate Requirement Levels
+
+## 1. Specification
+
+### 1.1 Spec A
+
+### 1.2 Spec B
+
+## 2. Interfaces
+
+### 2.1 Interface A
+
+The following interface MUST be implemented by compatible ...
+
+```php
+namespace ...;
+
+interface ...
+{
+}
+```
+
+### 2.2 Inteface B
+
+The following interface MUST be implemented by compatible ...
+
+```php
+namespace ...;
+
+interface ...
+{
+}
+```