+ { /* ... */ }
+
+ );
+}
+```
+
+A component's class name should **never** be used outside its own folder (with rare exceptions such as [`_z-index.scss`](https://github.com/WordPress/gutenberg/blob/master/assets/stylesheets/_z-index.scss)). If you need to inherit styles of another component in your own components, you should render an instance of that other component. At worst, you should duplicate the styles within your own component's stylesheet. This is intended to improve maintainability by treating individual components as the isolated abstract interface.
+
+#### SCSS File Naming Conventions for Blocks
+
+The build process will split SCSS from within the blocks library directory into two separate CSS files when Webpack runs.
+
+Styles placed in a `style.scss` file will be built into `blocks/build/style.css`, to load on the front end theme as well as in the editor. If you need additional styles specific to the block's display in the editor, add them to an `editor.scss`.
+
+Examples of styles that appear in both the theme and the editor include gallery columns and drop caps.
+
+## JavaScript
+
+### Imports
+
+In the Gutenberg project, we use [the ES2015 import syntax](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import) to enable us to create modular code with clear separations between code of a specific feature, code shared across distinct WordPress features, and third-party dependencies.
+
+These separations are identified by multi-line comments at the top of a file which imports code from another file or source.
+
+#### External Dependencies
+
+An external dependency is third-party code that is not maintained by WordPress contributors, but instead [included in WordPress as a default script](https://developer.wordpress.org/reference/functions/wp_enqueue_script/#default-scripts-included-and-registered-by-wordpress) or referenced from an outside package manager like [npm](https://www.npmjs.com/).
+
+Example:
+
+```js
+/**
+ * External dependencies
+ */
+import moment from 'moment';
+```
+
+#### WordPress Dependencies
+
+To encourage reusability between features, our JavaScript is split into domain-specific modules which [`export`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/export) one or more functions or objects. In the Gutenberg project, we've distinguished these modules under top-level directories. Each module serve an independent purpose, and often code is shared between them. For example, in order to localize its text, editor code will need to include functions from the `i18n` module.
+
+Example:
+
+```js
+/**
+ * WordPress dependencies
+ */
+import { __ } from '@wordpress/i18n';
+```
+
+#### Internal Dependencies
+
+Within a specific feature, code is organized into separate files and folders. As is the case with external and WordPress dependencies, you can bring this code into scope by using the `import` keyword. The main distinction here is that when importing internal files, you should use relative paths specific to top-level directory you're working in.
+
+Example:
+
+```js
+/**
+ * Internal dependencies
+ */
+import VisualEditor from '../visual-editor';
+```
+
+### Experimental and Unstable APIs
+
+Experimental and unstable APIs are temporary values exported from a module whose existence is either pending future revision or provides an immediate means to an end.
+
+_To External Consumers:_
+
+**There is no support commitment for experimental and unstable APIs.** They can and will be removed or changed without advance warning, including as part of a minor or patch release. As an external consumer, you should avoid these APIs.
+
+_To Project Contributors:_
+
+An experimental or unstable API is named as such to communicate instability of a function whose interface is not yet finalized. Aside from references within the code, these APIs should neither be documented nor mentioned in any CHANGELOG. They should effectively be considered to not exist from an external perspective. In most cases, they should only be exposed to satisfy requirements between packages maintained in this repository.
+
+An experimental or unstable function or object should be prefixed respectively using `__experimental` or `__unstable`.
+
+```js
+export { __experimentalDoExcitingExperimentalAction } from './api';
+export { __unstableDoTerribleAwfulAction } from './api';
+```
+
+- An **experimental API** is one which is planned for eventual public availability, but is subject to further experimentation, testing, and discussion.
+- An **unstable API** is one which serves as a means to an end. It is not desired to ever be converted into a public API.
+
+In both cases, the API should be made stable or removed at the earliest opportunity.
+
+While an experimental API may often stabilize into a publicly-available API, there is no guarantee that it will. The conversion to a stable API will inherently be considered a breaking change by the mere fact that the function name must be changed to remove the `__experimental` prefix.
+
+### Objects
+
+When possible, use [shorthand notation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#New_notations_in_ECMAScript_2015) when defining object property values:
+
+```js
+const a = 10;
+
+// Bad:
+const object = {
+ a: a,
+ performAction: function() {
+ // ...
+ },
+};
+
+// Good:
+const object = {
+ a,
+ performAction() {
+ // ...
+ },
+};
+```
+
+### Strings
+
+String literals should be declared with single-quotes *unless* the string itself contains a single-quote that would need to be escaped–in that case: use a double-quote. If the string contains a single-quote *and* a double-quote, you can use ES6 template strings to avoid escaping the quotes.
+
+**Note:** The single-quote character (`'`) should never be used in place of an apostrophe (`’`) for words like `it’s` or `haven’t` in user-facing strings. For test code it's still encouraged to use a real apostrophe.
+
+In general, avoid backslash-escaping quotes:
+
+```js
+// Bad:
+const name = "Matt";
+// Good:
+const name = 'Matt';
+
+// Bad:
+const pet = 'Matt\'s dog';
+// Also bad (not using an apostrophe):
+const pet = "Matt's dog";
+// Good:
+const pet = 'Matt’s dog';
+// Also good:
+const oddString = "She said 'This is odd.'";
+```
+
+You should use ES6 Template Strings over string concatenation whenever possible:
+
+```js
+const name = 'Stacey';
+
+// Bad:
+alert( 'My name is ' + name + '.' );
+// Good:
+alert( `My name is ${ name }.` );
+```
+
+## PHP
+
+We use
+[`phpcs` (PHP\_CodeSniffer)](https://github.com/squizlabs/PHP_CodeSniffer) with the [WordPress Coding Standards ruleset](https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards) to run a lot of automated checks against all PHP code in this project. This ensures that we are consistent with WordPress PHP coding standards.
+
+The easiest way to use PHPCS is [local environment](/docs/contributors/getting-started.md#local-environment). Once that's installed, you can check your PHP by running `npm run lint-php`.
+
+If you prefer to install PHPCS locally, you should use `composer`. [Install `composer`](https://getcomposer.org/download/) on your computer, then run `composer install`. This will install `phpcs` and `WordPress-Coding-Standards` which you can then run via `composer lint`.
diff --git a/gb-src/docs/contributors/copy-guide.md b/gb-src/docs/contributors/copy-guide.md
new file mode 100644
index 0000000000000..a3178b69109b3
--- /dev/null
+++ b/gb-src/docs/contributors/copy-guide.md
@@ -0,0 +1,284 @@
+# Copy Guidelines
+
+## Longer Text
+Guidelines for writing multi-line/step instructions or narrative introductions/orientation to pages or features.
+
+This will obviously vary quite a lot depending on the context, but here are some general tips:
+
+#### ONE: Contractions are your friends!
+They’re more conversational, and a simple way to make text sound friendlier and less formal. (And they save a bit of space as well: a win-win.)
+
+#### TWO: Cut phrases that inflate your word count without actually adding meaning.
+This happens frequently in two specific instances. First, when writing in the passive voice:
+
+> This block can be used to display single images.
+
+Any time you see phrases like “can be” or “is used”: halt. You’re writing in the passive voice. Try going active for a snappier (and shorter) sentence:
+
+> This block displays single images.
+
+Second, this happens when we hedge instead of making declarative statements:
+
+> The gallery block can help you display multiple images in an elegant layout.
+
+Does it or doesn’t it? We’re making this software: we’re allowed to be declarative about what it is and does:
+
+> The gallery block displays multiple images in an elegant layout.
+
+We also all do this a lot with the phrase “allows you to.”
+
+> Preformatted text allows you to keep your tabs and line breaks.
+
+Features don’t allow anyone to do anything; they’re just tools that do specific things to achieve an end. Just say what they do:
+
+> Preformatted text preserves your tabs and line breaks.
+
+The more direct sentences are almost always clearer. Scan your copy for the words “can,” “be,” “might,” “allows you to,” and “helps”—they’re the most common culprits, and looking for those words specifically is a way to locate phrasing you can tighten up.
+
+#### THREE: Beware of “simple,” “easy,” and “just.”
+It is not for us to decide what is simple: it’s for the user to decide. If we say something is easy and the user doesn’t have an easy experience, it undermines their trust in us and what we’re building. Same goes for “just”—many of us know to avoid “simple,” but still use “just” all the time. “Just click here.” “Just enter your username.” It’s the same thing: it implies that something will be no big deal, but we can’t know what the user will find to be a big deal.
+
+It’s also safer and more helpful to be specific. “Easy” and “simple” are shorthand for explanations that we haven’t written; whenever you see them, take a minute to think about what they’re standing in for. Maybe “It’s easy to add a block by hitting ‘enter’” really means “You can add more content to the page without taking your hands off the keyboard.” Great! Say the specific thing instead of relying on “easy.”
+
+This isn’t to say that you should banish these words from your vocabulary. You might want to write a tooltip describing how the cover image block now requires less configuration, or an email about how we’re building a tool for quick creation of custom blocks, and you could legitimately say that the cover image block has been simplified or that we’re working to make custom block creation easier—there, the terms are descriptive and relative. But be on the lookout for ways you might be using (or overusing) them to make absolute claims that something is easy or simple, and use those as opportunities to be more specific and clear.
+
+#### FOUR: Look out for “we.”
+Any time text or instructions uses “we” a lot, it means the focus of the text is on the people behind the software and not the people using the software. Sometimes that’s what you actually want—but it’s usually not. The focus should typically be on the user, what they need, and how they benefit rather than “what we did” or “what we want.”
+
+We’re the only ones that care about what we did or want; the user just wants software that works. If you see a lot of “we”s, think about whether you should reframe what you’re writing to focus on the benefits to and successes of the user.
+
+## Bulleted Lists
+Guidelines for (duh) writing bulleted lists.
+
+#### ONE: Keep sentence structures parallel across all bullets.
+Parallel structure makes lists easier to read quickly—their predictability takes some cognitive load off the reader.
+
+GOOD:
+> What can you do with this block? Lots of things!
+> * Add a quote.
+> * Highlight a link.
+> * Display multiple images.
+> * Create a bulleted list.
+
+Every bullet is a full sentence, and ends with a period. (If your list is a bunch of one- or two-word items, those can often just turn into a single regular sentence—easier to read, and space-saving.) Every line begins with a verb that tells the user what the block can do. The subject of the sentence is always the user.
+
+A user can absorb this list quickly because once they read the first item, they understand how to read the rest and know what information they’ll find.
+
+LESS GOOD:
+> What can you do with this block? Lots of things!
+> * You can add a quote.
+> * Highlighting a link you love.
+> * It displays multiple images. Nice for galleries!
+> * Bulleted lists
+
+Here, every line has different phrasing (some start with a verb, some with a noun) and the subject of the sentence changes (sometimes it’s you, sometimes it’s the block). Some lines have added description, some don't. There’s an incomplete sentence, and punctuation is inconsistent.
+
+Reading this list takes more work because the reader has to parse each bullet anew. They can’t assume each bullet will contain similar information.
+
+Note: this doesn't mean every bullet has to be super short and start with an action verb! “Predictable” doesn’t have to mean “simple.” It just means that each bullet should have the same sentence structure. This list would also be fine:
+
+> What can you do with this block? Lots of things!
+> * Try adding a quote. Sometimes someone else said things best!
+> * Use it to highlight a link you love—sharing links is the currency of the internet.
+> * Create a gallery that displays multiple images, and show off your best photos.
+
+Here, each bullet starts with a more user-focused verb and includes a piece of supplemental information for more interest. The punctuation varies a bit, which keeps the lines from feeling too formulaic, but since the basic structure of each is the same, they remain easy to read.
+
+#### TWO: When in doubt, start with a verb. (But not always the same verb.)
+Do you have to start with a verb? No. But if you’re at a loss, you usually can’t go wrong with a verb (especially since bulleted lists are often describing a series of actions or possible actions).
+
+In a simple list that’s meant to be purely instructional (e.g., in UI copy where you just need the user to make a decision), it might be fine to start every bullet with the same verb:
+
+> To continue, choose an action:
+> * Add a simple text block.
+> * Add a pullquote block.
+> * Add an image block.
+
+If your list is more persuasive (e.g., trying to convince someone to use a feature by listing its benefits) or includes multi-step instructions, you’ll want to vary your verbs to keep the reader engaged with more interesting language, as in the example above:
+
+>What can you do with this block? Lots of things!
+>* Try adding a quote. Sometimes someone else said things best!
+>* Use it to highlight a link you love—sharing links is the currency of the internet.
+>* Create a gallery that displays multiple images, and show off your best photos.
+
+These aren’t hard-and-fast rules—you might choose the use the same verb in a persuasive list to be more focused and powerful, for example. But they’re good starting places for solid lists.
+
+#### THREE: When something's clearly a list, you don't have to tell us it's a list.
+
+GOOD:
+> What can you do with this block? Lots of things!
+> * Add a quote.
+> * Highlight a link you love.
+> * Display multiple images.
+
+LESS GOOD:
+> What can you do with this block? Lots of things! Here are some examples of ways you can use it.
+> * You can add a quote.
+> * Highlighting a link you love.
+> * It displays multiple images. Nice for galleries!
+
+Find the balance between being as clear as possible and trusting a user. On one hand, we know that people don’t always read instructions; on the other, redundancy can make the user feel like we think they’re stupid.
+
+#### FOUR: Bold is sometimes your friend.
+Use it to focus readers on the key information in a bulleted list. This is especially useful when your bullets include some supplemental but ultimately secondary information.
+
+“Key information” is, well, key: bold draws the eye, so stick to the most vital piece of information in a given bullet:
+
+>What can you do with this block? Lots of things!
+> * Try adding a **quote**. Sometimes someone else said things best!
+> * Use it to highlight a **link** you love—sharing links is the currency of the internet.
+> * Create a **gallery** that displays multiple images, and show off your best photos.
+
+On the flipside, bolding too many things creates visual confusion:
+
+> **What can you do with this block?** Lots of things!
+> * Try adding a **quote**. Sometimes someone else said things best!
+> * Use it to highlight a **link** you love—sharing **links** is the currency of the internet.
+> * Create a **gallery** that displays **multiple images**, and show off your best **photos**.
+
+When lists are short and basic, don't bother—bolding just adds busy-ness.
+
+> What can you do with this block? Lots of things!
+> * Add a **quote**.
+> * Highlight a **link**.
+> * Display multiple **images**.
+
+The lack of words creates its own focus; you don't have to add any more.
+
+## UI Descriptions
+Guidelines for writing one-line feature descriptions, or short descriptions to clarify options.
+
+#### ONE: Clarity above all!
+If the user doesn't understand what using a particular option will result in, it doesn't matter how clever your pun is. Wordplay and idioms are frequently unclear, and easily misunderstood. If you use them at all, they should be as supplemental information— never to explain the main idea—and they should be something you’re fairly certain will be understandable to a pretty wide range of people.
+
+#### TWO: Refer back to section one, and look out for those bulk-adding phrases.
+Active voice is typically the better way to go, and cutting out the bulky phrasing is particularly important when you’ve got limited space and you need people to be able to make decisions and act. Often you can shorten a UI instruction phrase to be both shorter and clearer:
+
+> When you click X, Y happens.
+
+vs.
+
+> Click X to do Y.
+
+While it can feel like adding the extra words helps walk a user through the product, the extra words just serve to obscure the point being communicated:
+
+> When you click the “settings” button, the pop-up will display the advanced settings that are available.
+
+vs.
+
+> Click “settings” to access the advanced settings.
+
+Similar phrases are “Once you do X…” or “If you want to do X…” Sometimes there are decision points where “If you want to do X…” is entirely appropriate because there are different paths the user can take based on their goal. But, we often use it to mean “Here is a thing you can do,” which you can express more simply as: “To do X…”
+
+#### THREE: Be specific.
+When an action depends on the user having completed some prior action, be specific about what’s required and what happens next. We often default to “when you’re ready.”
+Ready for what? Be specific about whatever the prerequisites are.
+
+“When you’re ready” can mean:
+
+* When you want to add another block”
+* When you’re satisfied with your post”
+* After you’ve finished proofreading your post”
+* When you’d like to add a featured image”
+* After you’ve configured all the settings”
+
+And when something means everything, it actually means nothing. The more specific instructions are, the more useful they are, and the more trust the person following them will have in the product.
+
+#### FOUR: This is still writing. It should have personality and interest.
+Clarity above all, yes, and space is often limited here—but UI text can still be interesting to read.
+
+Single lines of description can still be complete sentences.
+
+> List. Numbered or bulleted.
+
+vs.
+
+> Add a list, either numbered or bulleted.
+
+You can still use contractions.
+
+> Add a list. We will provide formatting options.
+
+vs.
+
+> Add a bulleted list—we’ll give you some formatting options.
+
+You can still use punctuation—em dashes, colons, semicolons—to control the flow of your words, link ideas, and create pauses.
+
+> List. Numbered or bulleted.
+
+vs.
+
+> Add a list—numbered or bulleted. Your choice!
+
+You can still try to avoid jargon in favor of plain language.
+
+> Add unordered or ordered list.
+
+vs.
+
+> Add a list, either numbered or bulleted.
+
+(And because it bears repeating: no wordplay, please! “Personality” can—and in UI instructions, should—be subtle. We’re talking about text that sounds like it was said by a human being, not forced attempts at whimsy.)
+
+#### FIVE: Pay attention to capitalization.
+When it comes to headlines and subheads, there are two ways to capitalize:
+
+In Title Case, the First Letter of Almost Every Word Is Capitalized
+
+In sentence case, only the first letter of the line is capitalized
+
+Feature names and dashboard sections typically use title case (think “Site Stats” or “Recently Published”), whereas feature labels typically use sentence case (like “Show buttons on” or “Comment Likes are,” where “Likes” is capitalized because it’s the feature name, but the overall label is using sentence case).
+
+When you’re looking at a full page of UI copy, make sure you’re being consistent across all of it, and that all similar kinds of copy—headlines, tooltips, buttons, etc.—are using the same case.
+
+## Error Messaging
+Guidelines for writing error messages that are understandable and useful.
+
+#### ONE: Don’t ignore voice/tone in error messaging—they communicate a lot.
+Voice and tone can say as much as the individual words themselves. Error messages have to convey a significant amount of information and usually need to be fairly short, but try not to sacrifice tone, or to go too far in either a negative or positive direction.
+
+Let’s say someone’s trying to publish a post, but their user role doesn’t allow them to do that. Here are some ways we could—but should not—communicate that:
+
+> Your user role is incorrect.
+
+Here, we sound distant and uncaring.
+
+> Stop! You do not have permission to do this.
+
+Here, we sound unnecessarily alarmist and stern.
+
+> Oopsie, we can’t let you do that!
+
+Here, we sound too cute.
+
+We can stay direct, positive, and friendly, even in error messages. How? With tips two through four!
+
+#### TWO: Whenever possible, offer a path to resolution.
+A good error message doesn’t just alert someone to the fact that something is wrong.
+
+> Your user role is incorrect.
+
+Okay, fine. Why does that matter? What do I do about it? How does this message help me? I need to know why my user role matters, and how to get the role I need so I can complete the action I want to complete. An error message that doesn’t provide any instruction leaves the user without a path forward; they can’t avoid repeating the action that led to the error if we don’t tell them now.
+
+#### THREE: Don’t lean on jargon to cut down on words when space is tight.
+
+> Your user role is incorrect. Contact a site administrator.
+
+Maybe we’re getting somewhere here: now I know there’s something I can do about things, which is good.
+
+Then again, maybe we’re not: I still don’t know what my role is, or why it matters. Also, now I’m also not sure what a site administrator is, who mine is, or how to contact them.
+
+All the information in this error message is technically entirely correct, but that doesn’t mean it communicates anything useful. If the goal is understanding and resolution, technical accuracy doesn’t always get us there.
+
+“Your account does not have permission to publish posts” doesn’t use the language of the user roles UI, but it does explain what’s gone wrong and I can understand it even if I don’t know what a user role is. And since I understand, I’m also better placed to understand the resolution, even if the message ended here: I can see that I need to get permission.
+
+Consistency with existing UI language is great, but not when it gets in the way of understanding.
+
+#### FOUR: Don’t assume people understand where the error came from.
+
+> Your user role is incorrect.
+
+It might seem obvious to us that the user got this message when they tried to publish something or change a setting that they don’t have permission for. It might not be so obvious to the user: people click around a lot, especially when we’re unsure how to do something, and we don’t always remember what page or setting we were just looking at (or why!).
+
+A good error message also includes some context that orients the user. “Your account does not have permission to publish posts” reminds them that they were trying to publish a post, and that that’s the particular stumbling block that caused the error.
diff --git a/gb-src/docs/contributors/design.md b/gb-src/docs/contributors/design.md
new file mode 100644
index 0000000000000..d71221003d378
--- /dev/null
+++ b/gb-src/docs/contributors/design.md
@@ -0,0 +1,66 @@
+# Design Principles & Vision
+
+This is a living document that outlines the design principles and patterns of the editor interface. Its aim is to explain the background of the design, inform future improvements, and help people design great blocks.
+
+## Principles
+
+
+
+### Goal of Gutenberg
+
+Gutenberg's all-encompassing goal is a post- and page-building experience that makes it easy to create rich layouts. The block editor was the first product launched following this methodology for working with content.
+
+From the [kickoff post](https://make.wordpress.org/core/2017/01/04/focus-tech-and-design-leads/):
+
+> The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.
+
+We can extract a few key principles from this:
+
+- **Authoring rich posts is a key strength of WordPress.**
+- **Blocks will unify features and types of interaction under a single interface.** Users shouldn’t have to write shortcodes, custom HTML, or paste URLs to embed. Users only need to learn how the block works in order to use all of its features.
+- **Make core features more discoverable**, reducing hard-to-find “Mystery meat.” WordPress supports a large number of blocks and 30+ embeds. Let’s increase their visibility.
+
+### Why
+
+One thing that sets WordPress apart from other systems is that it allows users to create as rich a post layout as they can imagine — as long as they know HTML and CSS and build a custom theme.
+
+Gutenberg reshapes the editor into a tool that allows users write rich posts and build beautiful layouts in a few clicks — no technical knowledge needed. WordPress will become a powerful and flexible content tool that’s accessible to all.
+
+### Vision
+
+Gutenberg wants to make it easier to author rich content. This means ensuring good defaults, bundling advanced layout options into blocks, and making the most important actions immediately available. Authoring content with WordPress should be accessible to anyone.
+
+**Everything on a WordPress website becomes a block:** text, images, galleries, widgets, shortcodes, and even chunks of custom HTML, whether added by plugins or otherwise. Users will only have to learn a single interface —— the block interface.
+
+**All blocks are created equal.** They all live in the same inserter interface. Recency, search, tabs, and grouping ensure that the most-used blocks are within easy reach.
+
+**Drag-and-drop is secondary.** For greater accessibility and platform compatibility, drag-and-drop interactions are used as an additive enhancement on top of explicit actions like click, tab, and space.
+
+**Placeholders are key.** If a block can have a neutral placeholder state, it should. An image placeholder block shows a button to open the media library, and a text placeholder block shows a writing prompt. By embracing placeholders we can predefine editable layouts, so all users have to do is fill in the blanks.
+
+**Direct manipulation is intuitive.** The block interface allows users to manipulate content directly on the page. Plugin and theme authors will support and extend this experience by building their own custom blocks.
+
+**Code editing shouldn't be necessary for customization.** Customizing traditionally required complicated markup, and complicated markup is easy to break. With Gutenberg, customizing becomes more intuitive — and safer. A developer will be able to provide custom blocks that directly render portions of a layout (a three column grid of features, for instance) and clearly specify what can be directly edited by the user. That means the user can update text, swap images, reduce the number of columns, without having to ask a developer, or worrying about breaking things.
+
+### Future Opportunities
+
+The initial phase of Gutenberg as described in the kickoff goal is primarily limited to the content area (specifically `post_content`) of posts and pages. Within those confines, we are embracing the web as a vertical river of content by appending blocks sequentially, then adding layout options to each block.
+
+That said, there isn’t any fixed limit to the kind of layouts Gutenberg will be able to create. It’s very possible for Gutenberg to grow beyond the confines of post and page content, to include the whole page — one could think of a theme template as a comma-separated list of blocks, like this:
+
+```js
+{
+ 'theme/header',
+ 'theme/sidebar',
+ 'core/content' {
+ 'core/cover-image',
+ 'theme/author-card',
+ 'core/text',
+ },
+ 'theme/footer',
+}
+```
+
+Every block nested inside the content block would be _rearrangeable_. Every block would be _editable_. Every block would use the same API, and both the editor and the theme would load the same `style.css` file directly. In the end, both the editor/page builder and theme/front-end would appear near-identical, allowing for a true WYSIWYG experience.
+
+This concept is speculative, but it’s one direction Gutenberg could go in the future.
diff --git a/gb-src/docs/contributors/develop.md b/gb-src/docs/contributors/develop.md
new file mode 100644
index 0000000000000..7b8ad300ee316
--- /dev/null
+++ b/gb-src/docs/contributors/develop.md
@@ -0,0 +1,15 @@
+# Developer Contributions
+
+Please also see [CONTRIBUTING.md](https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md) for general information about contributions to the Gutenberg repository.
+
+The following resources offer additional information for developers who wish to contribute to Gutenberg:
+
+* [Getting Started](/docs/contributors/getting-started.md).
+* [Git Workflow](/docs/contributors/git-workflow.md).
+* [Coding Guidelines](/docs/contributors/coding-guidelines.md) outline additional patterns and conventions used in the Gutenberg project.
+* [Testing Overview](/docs/contributors/testing-overview.md) for PHP and JavaScript development in Gutenberg.
+* [Gutenberg Block Grammar](/docs/contributors/grammar.md).
+* [Scripts](/docs/contributors/scripts.md) - a list of vendor and internal scripts available to plugin developers.
+* [Managing Packages](/docs/contributors/managing-packages.md).
+* [Gutenberg Release Process](/docs/contributors/release.md) - a checklist for the different type of releases for Gutenberg project.
+* [Localizing Gutenberg Plugin](/docs/contributors/localizing.md) - a guide on how to translate Gutenberg in your locale or language.
diff --git a/gb-src/docs/contributors/document.md b/gb-src/docs/contributors/document.md
new file mode 100644
index 0000000000000..43efc49c3db17
--- /dev/null
+++ b/gb-src/docs/contributors/document.md
@@ -0,0 +1,34 @@
+# Documentation Contributions
+
+Documentation for Gutenberg is maintained in the `/docs/` directory in the same Gutenberg Github repository. The docs are published every 15 minutes to the [Block Editor Handbook site](https://developer.wordpress.org/block-editor/).
+
+## New Document
+
+To add a new documentation page:
+
+1. Create a Markdown file in the [docs](https://github.com/WordPress/gutenberg/tree/master/docs) folder
+2. Add item to the [toc.json](https://github.com/WordPress/gutenberg/blob/master/docs/toc.json) hierarchy
+3. Update manifest.json by running `npm run docs:build`
+4. Commit manifest.json with other files updated
+
+## Using Links
+
+It's very likely that at some point you will want to link to other documentation pages. It's worth emphasizing that all documents can be browsed in different contexts:
+
+- Block Editor Handbook
+- GitHub website
+- npm website
+
+To create links that work in all contexts, you should use absolute path links without the `https://github.com/WordPress/gutenberg` prefix. You can reference files using the following patterns:
+
+- `/docs/*.md`
+- `/packages/*/README.md`
+- `/packages/components/src/**/README.md`
+
+This way they will be properly handled in all three aforementioned contexts.
+
+## Resources
+
+* [Copy Guidelines](/docs/contributors/copy-guide.md) for writing instructions, documentations, or other contributions to Gutenberg project.
+
+* [Tone and Voice Guide](https://make.wordpress.org/docs/handbook/documentation-team-handbook/tone-and-voice-guide/) from WordPress Documentation.
diff --git a/gb-src/docs/contributors/getting-started.md b/gb-src/docs/contributors/getting-started.md
new file mode 100644
index 0000000000000..3105b6a0aa15d
--- /dev/null
+++ b/gb-src/docs/contributors/getting-started.md
@@ -0,0 +1,70 @@
+# Getting Started
+
+Gutenberg is a Node.js-based project, built primarily in JavaScript.
+
+The first step is to install a recent version of Node. The easiest way (on MacOS, Linux, or Windows 10 with the Linux Subsystem) is by installing and running [nvm]. Once `nvm` is installed, you can install the correct version of Node by running `nvm install` in the Gutenberg directory.
+
+Once you have Node installed, run these scripts:
+
+```
+npm install
+npm run build
+```
+
+This will build Gutenberg, ready to be used as a WordPress plugin!
+
+If you don't have a local WordPress environment to load Gutenberg in, we can help get that up and running, too.
+
+## Local Environment
+
+The quickest way to get up and running is to use the provided Docker setup. If you don't already have it, you'll need to install Docker by following their instructions for [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/), [all other version of Windows](https://docs.docker.com/toolbox/toolbox_install_windows/), [macOS](https://docs.docker.com/docker-for-mac/install/), or [Linux](https://docs.docker.com/v17.12/install/linux/docker-ce/ubuntu/#install-using-the-convenience-script).
+
+Once Docker is installed and running, run this script to install WordPress, and build your local environment:
+
+```
+npm run env install
+```
+
+WordPress will be installed in the `wordpress` directory, if you need to access WordPress core files directly, you can find them there.
+
+If you already have WordPress checked out in a different directory, you can use that installation, instead, by running these commands:
+
+```
+export WP_DEVELOP_DIR=/path/to/wordpress-develop
+npm run env connect
+```
+
+This will use WordPress' own local environment, and mount your Gutenberg directory as a volume there.
+
+In Windows, you can set the `WP_DEVELOP_DIR` environment variable using the appropriate method for your shell:
+
+ CMD: set WP_DEVELOP_DIR=/path/to/wordpress-develop
+ PowerShell: $env:WP_DEVELOP_DIR = "/path/to/wordpress-develop"
+
+The WordPress installation should be available at `http://localhost:8889` (**Username**: `admin`, **Password**: `password`).
+If this port is in use, you can override it using the `LOCAL_PORT` environment variable. For example, `export LOCAL_PORT=7777` will change the URL to `http://localhost:7777` . If you're running [e2e tests](/docs/contributors/testing-overview.md#end-to-end-testing), this change will be used correctly.
+
+To bring down this local WordPress instance later run `npm run env stop`. To bring it back up again, run `npm run env start`.
+
+WordPress comes with specific [debug systems](https://wordpress.org/support/article/debugging-in-wordpress/) designed to simplify the process as well as standardize code across core, plugins and themes. It is possible to use environment variables (`LOCAL_WP_DEBUG` and `LOCAL_SCRIPT_DEBUG`) to update a site's configuration constants located in `wp-config.php` file. Both flags can be disabled at any time by running the following command:
+```
+LOCAL_SCRIPT_DEBUG=false LOCAL_WP_DEBUG=false npm run env install
+```
+By default, both flags will be set to `true`.
+
+## On A Remote Server
+
+Open a terminal (or if on Windows, a command prompt) and navigate to the repository you cloned. Now type `npm install` to get the dependencies all set up. Once that finishes, you can type `npm run build`. You can now upload the entire repository to your `wp-content/plugins` directory on your web server and activate the plugin from the WordPress admin.
+
+You can also type `npm run package-plugin` which will run the two commands above and create a zip file automatically for you which you can use to install Gutenberg through the WordPress admin.
+
+[npm]: https://www.npmjs.com/
+[nvm]: https://github.com/creationix/nvm
+
+## Playground
+
+The Gutenberg repository also includes a static Gutenberg playground that allows testing and developing in a WordPress-agnostic context. This is very helpful for developing reusable components and trying generic JavaScript modules without any backend dependency.
+
+You can launch the playground by running `npm run playground:start` locally. The playground should be available on [http://localhost:1234](http://localhost:1234).
+
+You can also test the playground version of the current master branch on GitHub Pages: [https://wordpress.github.io/gutenberg/](https://wordpress.github.io/gutenberg/)
diff --git a/gb-src/docs/contributors/git-workflow.md b/gb-src/docs/contributors/git-workflow.md
new file mode 100644
index 0000000000000..7f1499bc7de34
--- /dev/null
+++ b/gb-src/docs/contributors/git-workflow.md
@@ -0,0 +1,65 @@
+# Git Workflow
+
+A good workflow for new contributors to follow is listed below:
+- Fork Gutenberg repository
+- Clone forked repository
+- Create a new branch
+- Make code changes
+- Commit code changes within the newly created branch
+- Push branch to forked repository
+- Submit Pull Request to Gutenberg repository
+
+Ideally name your branches with prefixes and descriptions, like this: `[type]/[change]`. A good prefix would be:
+
+- `add/` = add a new feature
+- `try/` = experimental feature, "tentatively add"
+- `update/` = update an existing feature
+
+For example, `add/gallery-block` means you're working on adding a new gallery block.
+
+You can pick among all the = $(!Block .)* (Block $(!Block .)*)* $(.*)
= Block_Void
+ / Block_Balanced
= "<!--" __ "wp:" Block_Name __ (Block_Attributes __)? "/-->"
= Block_Start (Block / $(!Block_End .))* Block_End
= "<!--" __ "wp:" Block_Name __ (Block_Attributes __)? "-->"
= "<!--" __ "/wp:" Block_Name __ "-->"
= Namespaced_Block_Name
+ / Core_Block_Name
= $(Block_Name_Part "/" Block_Name_Part)
= $(Block_Name_Part)
= $([a-z] [a-z0-9_-]*)
- JSON-encoded attributes embedded in a block's opening comment
= $("{" (!("}" __ "" "/"? "-->") .)* "}") = [ \t\r\n]+
diff --git a/gb-src/docs/contributors/history.md b/gb-src/docs/contributors/history.md
new file mode 100644
index 0000000000000..a0f05a9cb446a
--- /dev/null
+++ b/gb-src/docs/contributors/history.md
@@ -0,0 +1,19 @@
+# History
+
+## Survey
+There was a survey done: [https://make.wordpress.org/core/2017/04/07/editor-experience-survey-results/](https://make.wordpress.org/core/2017/04/07/editor-experience-survey-results/)
+
+## Inspiration
+This includes a list of historical articles and influences on the Gutenberg project.
+
+- LivingDocs: [https://beta.livingdocs.io/articles](https://beta.livingdocs.io/articles)
+- Parrot: [https://intenseminimalism.com/2017/parrot-an-integrated-site-builder-and-editor-concept-for-wordpress/](https://intenseminimalism.com/2017/parrot-an-integrated-site-builder-and-editor-concept-for-wordpress/)
+- Apple Keynote
+- Slack
+- Google Sites v2
+
+## Blog posts by the team
+
+- Gutenberg tag on make/core: updates and much more: [https://make.wordpress.org/core/tag/gutenberg/](https://make.wordpress.org/core/tag/gutenberg/)
+- Suggested revised timeline: [https://make.wordpress.org/core/2017/08/11/revised-suggested-roadmap-for-gutenberg-and-customization/](https://make.wordpress.org/core/2017/08/11/revised-suggested-roadmap-for-gutenberg-and-customization/)
+- Discovering Gutenberg: [https://make.wordpress.org/core/2017/08/08/discovering-gutenberg-and-next-steps/](https://make.wordpress.org/core/2017/08/08/discovering-gutenberg-and-next-steps/)
diff --git a/gb-src/docs/contributors/localizing.md b/gb-src/docs/contributors/localizing.md
new file mode 100644
index 0000000000000..66d8df9568296
--- /dev/null
+++ b/gb-src/docs/contributors/localizing.md
@@ -0,0 +1,9 @@
+# Localizing Gutenberg Plugin
+
+To translate Gutenberg in your locale or language, [select your locale here](https://translate.wordpress.org/projects/wp-plugins/gutenberg) and translate *Development* (which contains the plugin's string) and/or *Development Readme* (please translate what you see in the Details tab of the [plugin page](https://wordpress.org/plugins/gutenberg/)).
+
+A Global Translation Editor (GTE) or Project Translation Editor (PTE) with suitable rights will process your translations in due time.
+
+Language packs are automatically generated once 95% of the plugin's strings are translated and approved for a locale.
+
+The inclusion of Gutenberg into WordPress core means that more than 51% of WordPress installations running a translated WordPress installation have Gutenberg's translated strings compiled into the core language pack as well.
diff --git a/gb-src/docs/contributors/managing-packages.md b/gb-src/docs/contributors/managing-packages.md
new file mode 100644
index 0000000000000..000a74026469f
--- /dev/null
+++ b/gb-src/docs/contributors/managing-packages.md
@@ -0,0 +1,8 @@
+# Managing Packages
+
+This repository uses [lerna] to manage Gutenberg modules and publish them as packages to [npm]. This enforces certain steps in the workflow which are described in details in [packages](/packages/README.md) documentation.
+
+Maintaining dozens of npm packages is difficult—it can be tough to keep track of changes. That's why we use `CHANGELOG.md` files for each package to simplify the release process. As a contributor you should add an entry to the aforementioned file each time you contribute adding production code as described in [Maintaining Changelogs](/packages/README.md#maintaining-changelogs) section.
+
+[lerna]: https://lernajs.io/
+[npm]: https://www.npmjs.com/
diff --git a/gb-src/docs/contributors/outreach.md b/gb-src/docs/contributors/outreach.md
new file mode 100644
index 0000000000000..208a1eaf707e1
--- /dev/null
+++ b/gb-src/docs/contributors/outreach.md
@@ -0,0 +1,65 @@
+# Outreach
+
+This includes articles, talks, demos and anything the community is doing to discuss, learn about, and contribute to Gutenberg. This is not an exhaustive list; if we are missing your event or article, just let us know.
+
+## Articles
+
+A short list of useful articles around defining, extending, and contributing to Gutenberg.
+
+### Overviews of Gutenberg
+
+- [Gutenberg, or the Ship of Theseus](https://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/), Matías Ventura Bausero (October 2017)
+- [We Called It Gutenberg for a Reason](https://ma.tt/2017/08/we-called-it-gutenberg-for-a-reason/), Matt Mullenweg (August 2017)
+- [How Gutenberg is Changing WordPress Development](https://riad.blog/2017/10/06/how-gutenberg-is-changing-wordpress-development/), Riad Benguella (October 2017)
+- [How Gutenberg Will Shape the Future of WordPress](https://www.linkedin.com/pulse/gutenberg-morten-rand-hendriksen/), Morten Rand-Henrikson (August 2017)
+
+### Extending Gutenberg
+
+- [With Gutenberg, what happens to my Custom Fields?](https://riad.blog/2017/12/11/with-gutenberg-what-happens-to-my-custom-fields/), Riad Benguella (December 2017)
+- [One thousand and one ways to extend Gutenberg today](https://riad.blog/2017/10/16/one-thousand-and-one-way-to-extend-gutenberg-today/), Riad Benguella (October 2017)
+- [Gutenberg Plugin Boilerplate](https://github.com/ahmadawais/Gutenberg-Boilerplate/), Ahmad Awais (August 2017)
+
+### Community Contribution
+
+- [Gutenberg Block Library](https://editorblockswp.com/library), Danny Cooper (August 2018)
+- [A zero-configuration developer toolkit for building WordPress Gutenberg block plugins](https://ahmadawais.com/create-guten-block-toolkit/), Ahmad Awais (January 2018)
+- [Contributing to Gutenberg Without Code](https://wordimpress.com/a-pot-stirrer-amongst-chefs-contributing-to-gutenberg-without-code/), Kevin Hoffman (August 2017)
+- [Testing Flow in Gutenberg: Instructions for how to contribute to usability testing](https://make.wordpress.org/test/2017/11/22/testing-flow-in-gutenberg/), Anna Harrison (November 2017)
+
+### Article Compilations
+
+- [Curated Collection of Gutenberg Articles, Plugins, Blocks, Tutorials, etc](http://gutenberghub.com/), By Munir Kamal
+- [Articles about Gutenberg](https://github.com/WordPress/gutenberg/issues/1419) (Github Issue thread with links)
+- [Gutenberg articles on ManageWP.org](https://managewp.org/search?q=gutenberg)
+- [Gutenberg Times](https://gutenbergtimes.com/category/updates/)
+
+## Talks
+
+Talks given about Gutenberg, including slides and videos as they are available.
+
+### Slides
+- [The new core WordPress editor](http://kimb.me/talk-bigwp-london-new-core-wordpress-editor/) at BigWP London (18. May 2017)
+- [Gutenberg Notes](http://haiku2.com/2017/09/bend-wordpress-meetup-gutenberg-notes/) at Bend WordPress Meetup (5. September 2017)
+- [Gutenberg and the Future of Content in WordPress](https://www.slideshare.net/andrewmduthie/gutenberg-and-the-future-of-content-in-wordpress) (20. September 2017)
+- [Head first into Gutenberg](https://speakerdeck.com/prtksxna/head-first-into-gutenberg) at the [WordPress Goa Meet-up](https://www.meetup.com/WordPressGoa/events/245275573/) (1. December 2017)
+- [Gutenberg : vers une approche plus fine du contenu](https://imathi.eu/2018/02/16/gutenberg-vers-une-approche-plus-fine-du-contenu/) at [WP Paris](https://wpparis.fr/) (8. February 2018)
+
+### Videos
+- [All `Gutenberg` tagged Talks at WordPress.tv](https://wordpress.tv/tag/gutenberg/)
+- 2018-Jun - [Beyond Gutenberg](https://wordpress.tv/2018/07/09/matias-ventura-beyond-gutenberg/) by Matías Ventura
+- 2018-Jun - [Anatomy of a block: Gutenberg design patterns](https://wordpress.tv/2018/07/08/tammie-lister-anatomy-of-a-block-gutenberg-design-patterns/) by Tammie Lister
+- 2017-Dec - [State of the Word 2017](https://wordpress.tv/2017/12/04/matt-mullenweg-state-of-the-word-2017/) by Matt Mullenweg (Gutenberg demo by Matías Ventura at 35:00)
+- [Gutenberg is Coming (Don’t Be Afraid)](https://training.ithemes.com/webinar/gutenberg-is-coming-dont-be-afraid/) from iThemes Training
+
+## Showcases or demonstrations:
+
+https://wpleeds.co.uk/events/plugins-gutenberg-wordpress-leeds-july-2017/
+
+http://kimb.me/talk-bigwp-london-new-core-wordpress-editor
+
+https://www.facebook.com/events/278785795934302/
+
+https://www.meetup.com/WordPress-Melbourne/events/241543639
+
+https://wpmeetups.de/termin/29-wp-meetup-stuttgart-gutenberg-editor-rueckblick-wordcamp-europe/
+
diff --git a/gb-src/docs/contributors/principles.md b/gb-src/docs/contributors/principles.md
new file mode 100644
index 0000000000000..8acedac095826
--- /dev/null
+++ b/gb-src/docs/contributors/principles.md
@@ -0,0 +1,17 @@
+# Principles
+
+First, let’s look at the big picture. If the architectural and UX principles described here are activated at scale, how will the Gutenberg project improve and transform both users and creators experiences?
+
+How Gutenberg can transform the *user experience*:
+
+* Users can focus on conveying their ideas and information in the way they want without having to understand the underlying technical / semantic distinctions.
+* Users can add and edit functionality more easily via the unified mechanism of blocks.
+* Everything on a user’s site can be directly manipulated and edited in place without having to rely on traversing complex navigation menus and disparate sections.
+* Users only have to learn a single interface — the block — and a single way to add new elements. They will gain the confidence that comes from using a system that feels unified and clear, where everything works in a consistent manner.
+
+How Gutenberg can transform the *developer and designer experience*:
+
+* A powerful and expressive toolkit that allows crafting first-class experiences through standardized design and development processes.
+* This standardization allows for interoperability — developers can create components that seamlessly connect with components from other developers.
+* Relying on consistent UX patterns means developers can be confident their work will be immediately familiar and usable to users and that they don’t have to reinvent interaction patterns. They can focus on their product.
+* With one modern, flexible interface, the block, but many ways to bend it, makers have an opportunity to extend WordPress in many new ways.
diff --git a/gb-src/docs/contributors/principles/the-block.md b/gb-src/docs/contributors/principles/the-block.md
new file mode 100644
index 0000000000000..bdb0c920c77c1
--- /dev/null
+++ b/gb-src/docs/contributors/principles/the-block.md
@@ -0,0 +1,27 @@
+# Blocks are the Interface
+
+At the core of Gutenberg lies the concept of the block. From a technical point of view, blocks both raise the level of abstraction from a single document to a collection of meaningful elements, and they replace ambiguity—inherent in HTML—with explicit structure.
+
+From a user perspective, blocks allow any kind of content, media, or functionality to be directly added to their site in a more consistent and usable way. The “add block” button gives the user access to an entire library of options all in one place, rather than having to hunt through menus or know shortcodes.
+
+But most importantly, Gutenberg is built on the principle of *direct manipulation*, which means that the primary options for how an element is displayed are controlled *in the context of the block itself*. This is a big shift from the traditional WordPress model, where options that were often buried deep in layers of navigation menus controlled the elements on a page through indirect mechanisms.
+
+So, for example, a user can add an image, write its caption, change its width and layout, add a link around it, all from within the block interface in the canvas. The same principle should apply to more complex blocks, like a "navigation menu", with the user being able to add, edit, move, and finalize the full presentation of their navigation.
+
+* Users only need to learn one interface — the block — to add and edit everything on their site. Users shouldn’t have to write shortcodes, custom HTML, or understand hidden mechanisms to embed content.
+* Gutenberg makes core features more discoverable, reducing hard-to-find “Mystery meat.” WordPress supports a large number of blocks and 30+ embeds. Let’s increase their visibility.
+
+## Building Blocks
+
+What does this mean for designers and developers? The block structure plus the principle of direct manipulation mean thinking differently about how to design and develop WordPress components. Let’s take another look at the architecture of a block:
+
+
+
+### The primary interface for a block is the content area of the block.
+The placeholder content in the content area of the block can be thought of as a guide or interface for users to follow a set of instructions or “fill in the blanks” (more on placeholders later). Since the content area represents what will actually appear on the site, interaction here hews closest to the principle of direct manipulation and will be most intuitive to the user. This should be thought of as the primary interface for adding and manipulating content and adjusting how it is displayed.
+
+### The block toolbar is the place for critical options that can’t be incorporated into placeholder UI.
+Basic block settings won’t always make sense in the context of the placeholder / content UI. As a secondary option, options that are critical to the functionality of a block can live in the block toolbar. The block toolbar is one step removed from direct manipulation, but is still highly contextual and visible on all screen sizes, so it is a great secondary option.
+
+### The Settings Sidebar should only be used for advanced, tertiary controls.
+The Settings Sidebar is not visible by default on a small / mobile screen, and may also be collapsed even in a desktop view. Therefore, it should not be relied on for anything that is necessary for the basic operation of the block. Pick good defaults, make important actions available in the block toolbar, and think of the sidebar as something that only power users may discover.
diff --git a/gb-src/docs/contributors/readme.md b/gb-src/docs/contributors/readme.md
new file mode 100644
index 0000000000000..96c3a85424e5d
--- /dev/null
+++ b/gb-src/docs/contributors/readme.md
@@ -0,0 +1,18 @@
+# Contributor Documentation
+
+Welcome to the Gutenberg Project Contributors Guide.
+
+The following guidelines are in place to create consistency across the project and the numerous contributors. See the [Contributing Documentation](https://github.com/WordPress/gutenberg/blob/master/CONTRIBUTING.md) for technical details around setup, and submitting your contributions.
+
+## Philosophy
+
+* [Architectural and UX Principles of Gutenberg](/docs/contributors/principles.md)
+
+## Sections
+
+The contributors guide has the following different sections by contribution type:
+
+* [Design Contributions](/docs/contributors/design.md)
+* [Developer Contributions](/docs/contributors/develop.md)
+* [Documentation Contributions](/docs/contributors/document.md)
+
diff --git a/gb-src/docs/contributors/reference.md b/gb-src/docs/contributors/reference.md
new file mode 100644
index 0000000000000..95c0b603323e5
--- /dev/null
+++ b/gb-src/docs/contributors/reference.md
@@ -0,0 +1,17 @@
+# Reference
+
+- [Glossary](/docs/designers-developers/glossary.md)
+- [Coding Guidelines](/docs/contributors/coding-guidelines.md)
+- [Testing Overview](/docs/contributors/testing-overview.md)
+- [Frequently Asked Questions](/docs/designers-developers/faq.md)
+
+## Logo
+
+
+Released under GPL license, made by [Cristel Rossignol](https://twitter.com/cristelrossi).
+
+[Download the SVG logo](https://github.com/WordPress/gutenberg/blob/master/docs/final-g-wapuu-black.svg).
+
+## Mockups
+
+Mockup Sketch files are available in [the Design section](/docs/designers-developers/designers/design-resources.md).
diff --git a/gb-src/docs/contributors/release-screenshot.png b/gb-src/docs/contributors/release-screenshot.png
new file mode 100644
index 0000000000000000000000000000000000000000..63334f489c0b2cc08ddad7ce03a213b73f06e59f
GIT binary patch
literal 253325
zcmagF1z4Q1(kP5Or4)CH7k783xVu}?h2kty+@-ifp+IqWS=`-yan~Y?^K;I3|9ii4
z?sLAoPu_jANoJCnNhXuYY=nxE3_1!S3KSF+x}2<}8Wa=){`+Hrgz#R1_ZLF|3JRsg
zMnXbGPC|lQ