Add a proposals folder in docs and put the private beta stuff there

docs/proposals/private-beta-tasks.md

@@ -0,0 +1,70 @@
+**Polish the user experience**
+
+First and foremost, Atom is a **product**. Atom needs to feel familiar and
+inviting. This includes a solid introductory experience and parity with the most
+important features of Sublime Text.
+
+  * First launch UI and flow (actions below should be easily discoverable)
+    * Create a new file
+    * Open a project and edit an existing file
+    * Install a package
+    * Change settings (adjust theme, change key bindings, set config options)
+    * How to use command P
+  * Use collaboration internally
+  * How and where to edit keyBinding should be obvious to new users
+  * Finish find and replace in buffer/project
+  * Atom should start < 300ms
+  * Match Sublime's multiple selection functionality (#523)
+  * Fix softwrap bugs
+  * Menus & Context menus
+  * Track usage/engagement of our users (make this opted in?)
+  * Windows support
+  * Reliably and securely auto-update and list what's new
+  * Secure access to the keychain (don't give every package access to the keychain)
+  * Secure access to GitHub (each package can ask to have it's own oauth token)
+  * Don't crash when opening/editing large (> 10Mb) files
+  * Send js and native crash reports to a remote server
+
+**Lay solid groundwork for a package and theme ecosystem**
+
+Extensibility is one of Atom's key value propositions, so a smooth experience
+for creating and maintaining packages is just as important as the user
+experience. The package development, dependency and publishing workflow needs to
+be solid. We also want to have a mechanism for clearly communicating with
+package authors about breaking API changes.
+
+  * Finish APM backend (integrate with GitHub Releases)
+  * Streamline Dev workflow
+    * `api create` - create package scaffolding
+    * `apm test` - so users can run focused package tests
+    * `apm publish` - should integrate release best practices (ie npm version)
+  * Determine which classes and methods should be included in the public API
+  * Users can find/install/update/fork existing packages and themes
+  
+**Tighten up the view layer**
+Our current approach to the view layer need some improvement. We want to
+actively promote the use of the M-V-VM design pattern, provide some declarative
+event binding mechanisms in the view layer, and improve the performance of the
+typical package specs. We don't want the current approach to be used as an
+example in a bunch of new packages, so it's important to improve it now.
+
+  * Add marker view API
+
+**Get atom.io online with some exciting articles and documentation**
+We'd love to send our private alpha candidates to a nice site with information
+about what Atom is, the philosophies and technologies behind it, and guidance
+for how to get started.
+
+  * Design and create www.atom.io
+    * Guides
+      * Theme & Package creation guide
+    * Full API per release tag
+    * Changelog per release
+    * Explanation of features
+    * Explain Semver and general plans for the future (reassure developers we care about them)
+    * General Values/Goals
+  * Make docs accessible from Atom
+  * Community/contribution guidelines
+    * Is all communication to be done through issues?
+    * When should you publish a plugin?
+    * Do we need to vet plugins from a security perspective?

docs/proposals/private-beta-timeline.md

@@ -0,0 +1,16 @@
+## Proposed Timeline
+
+1. **October 30st** - Internal launch - persuade as many githubers to switch as
+possible.
+
+1. Triage bugs and identify what needs to be fixed before private alpha. Maybe
+talk to @chrissiebrodigan about doing a UX study.
+
+1. **November 22st** - Private alpha launch
+
+1. Trickle out invites as people ask/we need more testers.
+
+1. If our usage metrics/engagement metrics decrease, stop, identify the issue
+and fix it before continuing.
+
+1. Launch