4 files changed, 69 insertions, 26 deletions
diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index e67db9ff142..f83a60e49e8 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -7,6 +7,11 @@ storing data in a single JSON column the data is stored in a separate table.
 
 ## When To Use Background Migrations
 
+>**Note:**
+When adding background migrations _you must_ make sure they are announced in the
+monthly release post along with an estimate of how long it will take to complete
+the migrations.
+
 In the vast majority of cases you will want to use a regular Rails migration
 instead. Background migrations should _only_ be used when migrating _data_ in
 tables that have so many rows this process would take hours when performed in a
@@ -91,6 +96,10 @@ BackgroundMigrationWorker.perform_bulk_in(5.minutes, jobs)
 
 ## Cleaning Up
 
+>**Note:**
+Cleaning up any remaining background migrations _must_ be done in either a major
+or minor release, you _must not_ do this in a patch release.
+
 Because background migrations can take a long time you can't immediately clean
 things up after scheduling them. For example, you can't drop a column that's
 used in the migration process as this would cause jobs to fail. This means that
diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md
index 149a0159680..6ade3231fac 100644
--- a/doc/development/fe_guide/style_guide_js.md
+++ b/doc/development/fe_guide/style_guide_js.md
@@ -11,7 +11,7 @@ See [our current .eslintrc][eslintrc] for specific rules and patterns.
 
 #### ESlint
 
-1. **Never** disable eslint rules unless you have a good reason.  
+1. **Never** disable eslint rules unless you have a good reason.
 You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */`
 at the top, but legacy files are a special case.  Any time you develop a new feature or
 refactor an existing one, you should abide by the eslint rules.
@@ -100,26 +100,44 @@ followed by any global declarations, then a blank newline prior to any imports o
     export default Foo;
   ```
 
-1. Relative paths: Unless you are writing a test, always reference other scripts using
-relative paths instead of `~`
-  * In **app/assets/javascripts**:
+1. Relative paths: when importing a module in the same directory, a child
+directory, or an immediate parent directory prefer relative paths.  When
+importing a module which is two or more levels up, prefer either `~/` or `ee/`
+.
 
-    ```javascript
-      // bad
-      import Foo from '~/foo'
+In **app/assets/javascripts/my-feature/subdir**:
 
-      // good
-      import Foo from '../foo';
-    ```
-  * In **spec/javascripts**:
+``` javascript
+// bad
+import Foo from '~/my-feature/foo';
+import Bar from '~/my-feature/subdir/bar';
+import Bin from '~/my-feature/subdir/lib/bin';
 
-    ```javascript
-      // bad
-      import Foo from '../../app/assets/javascripts/foo'
+// good
+import Foo from '../foo';
+import Bar from './bar';
+import Bin from './lib/bin';
+```
 
-      // good
-      import Foo from '~/foo';
-    ```
+In **spec/javascripts**:
+
+``` javascript
+// bad
+import Foo from '../../app/assets/javascripts/my-feature/foo';
+
+// good
+import Foo from '~/my-feature/foo';
+```
+
+When referencing an **EE component**:
+
+``` javascript
+// bad
+import Foo from '../../../../../ee/app/assets/javascripts/my-feature/ee-foo';
+
+// good
+import Foo from 'ee/my-feature/foo';
+```
 
 1. Avoid using IIFE. Although we have a lot of examples of files which wrap their
 contents in IIFEs (immediately-invoked function expressions),
@@ -465,7 +483,7 @@ A forEach will cause side effects, it will be mutating the array being iterated.
 
 #### Vue and Boostrap
 1. Tooltips: Do not rely on `has-tooltip` class name for Vue components
-  ```javascript
+  ```javascript
     // bad
     <span
       class="has-tooltip"
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 161d2544169..9b8ab5da74e 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -35,12 +35,11 @@ Please don't depend on GitLab-specific code since it can change in future
 versions. If needed copy-paste GitLab code into the migration to make it forward
 compatible.
 
-## Commit Guidelines
+## Schema Changes
 
-Each migration **must** be added in its own commit with a descriptive commit
-message. If a commit adds a migration it _should only_ include the migration and
-any corresponding changes to `db/schema.rb`. This makes it easy to revert a
-database migration without accidentally reverting other changes.
+Migrations that make changes to the database schema (e.g. adding a column) can
+only be added in the monthly release, patch releases may only contain data
+migrations _unless_ schema changes are absolutely required to solve a problem.
 
 ## Downtime Tagging
 
@@ -224,9 +223,9 @@ add_column(:projects, :foo, :integer, default: 10, limit: 8)
 
 ## Timestamp column type
 
-By default, Rails uses the `timestamp` data type that stores timestamp data without timezone information.        
-The `timestamp` data type is used by calling either the `add_timestamps` or the `timestamps` method.       
-Also Rails converts the `:datetime` data type to the `timestamp` one.        
+By default, Rails uses the `timestamp` data type that stores timestamp data without timezone information.
+The `timestamp` data type is used by calling either the `add_timestamps` or the `timestamps` method.
+Also Rails converts the `:datetime` data type to the `timestamp` one.
 
 Example:
 
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index 42bb5e8619c..bfd80aab6a4 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -146,3 +146,20 @@ If new emoji are added, the spritesheet may change size. To compensate for
 such changes, first generate the `emoji.png` spritesheet with the above Rake
 task, then check the dimensions of the new spritesheet and update the
 `SPRITESHEET_WIDTH` and `SPRITESHEET_HEIGHT` constants accordingly.
+
+## Updating project templates
+
+Starting a project from a template needs this project to be exported. On a
+up to date master branch with run:
+
+```
+gdk run db
+# In a new terminal window
+bundle exec rake gitlab:update_project_templates
+git checkout -b update-project-templates
+git add vendor/project_templates
+git commit
+git push -u origin update-project-templates
+```
+
+Now create a merge request and merge that to master.