Add an Implementation Guide.

This is designed to help creators of new Sass implementations know where
to start and what to avoid.

source/implementation/index.html.haml

@@ -0,0 +1,66 @@
+---
+title: Implementation Guide
+---
+
+- content_for (:introduction) do
+  Sass has a thriving community of implementations, with more being produced all
+  the time. The core team loves to see new implementations thrive and mature,
+  and they want to help out in any way they can.
+
+:markdown
+  ## Resources
+
+  - [`sass-spec`](https://github.com/sass/sass-spec) is a suite of
+    implementation-agnostic test cases for verifying that a Sass implementation
+    behaves correctly. It's the best way to track your implementation's
+    compatibility with the Sass reference implementation.
+
+  - [How `@extend` Works](https://gist.github.com/nex3/7609394) is a fairly
+    comprehensive run-down of the algorithm used by Sass's trickiest feature.
+    Natalie still says that the implementation of `@extend` is the hardest code
+    she's ever had to write, but luckily you don't have to figure it out from
+    scratch.
+
+  - **Reach out!** If you're working on a new implementation, we want to hear
+    about it. Send an email to [Natalie](mailto:nex342@gmail.com) and
+    [Chris](mailto:chris@eppsteins.net), tell us about the cool work you're
+    doing, and ask about any corners of the language that don't quite make
+    sense.
+
+  ## Requirements
+
+  We whole-heartedly love new implementations of Sass, but we do have a few
+  restrictions that we ask those implementations to follow in order to call
+  themselves "Sass", "Sass implementations", or the like. Sass is a community as
+  much as it is a language, and it's important that all implementations are
+  willing to work for the good of the community.
+
+  First, we ask that every implementation adopt the [Sass community
+  guidelines](/community-guidelines) for their own implementation-specific
+  communities. Much of what makes the Sass community strong is a culture of
+  kindness and respect, and having clear and explicit guidelines helps produce
+  that culture.
+
+  Second, we ask that implementations not extend the language without agreement
+  from the other major implementations and from the language designers, Natalie
+  and Chris. The only reason a Sass community exists at all is because the
+  language enables styles and frameworks to be shared among designers, and it's
+  crucial for sharing that Sass code that works for one implementation works the
+  same for all of them. In addition, it's important that there be a unified
+  vision for the language design.
+
+  ## Making Language Changes
+
+  Sass can still evolve as a language, of course. We're working on putting
+  together a more explicit process for proposing and iterating on new language
+  features, but for now all discussion of changes happens on [the Sass issue
+  tracker](https://github.com/sass/sass/issues). Language changes are considered
+  final when they're part of a stable release of the Ruby reference
+  implementation.
+
+  Language changes are discussed collaboratively, with particular weight given
+  to the maintainers of mature Sass implementations. Attempts will be made to
+  reach consensus with all stakeholders. However, this may be impossible in some
+  circumstances, and the ultimate say lies with the lead designer of Sass,
+  Natalie. Chris, the other core designer, also has veto power over any language
+  change.