Add latest changes from gitlab-org/gitlab@master

3 files changed, 27 insertions, 4 deletions

diff --git a/doc/ci/runners/runners_scope.md b/doc/ci/runners/runners_scope.md
index d20ef846df7..43204b463b3 100644
--- a/doc/ci/runners/runners_scope.md
+++ b/doc/ci/runners/runners_scope.md
@@ -95,10 +95,8 @@ To disable shared runners for a group:
    select **Allow projects and subgroups to override the group setting**.
 
 NOTE:
-To re-enable the shared runners for a group, turn on the
-**Enable shared runners for this group** toggle.
-Then, a user with the Owner or Maintainer role must explicitly change this setting
-for each project subgroup or project.
+If you re-enable the shared runners for a group after you disable them, a user with the 
+Owner or Maintainer role must manually change this setting for each project subgroup or project.
 
 ### How shared runners pick jobs
 
diff --git a/doc/development/documentation/topic_types/tutorial.md b/doc/development/documentation/topic_types/tutorial.md
index 91f426147b5..2d57029b786 100644
--- a/doc/development/documentation/topic_types/tutorial.md
+++ b/doc/development/documentation/topic_types/tutorial.md
@@ -32,6 +32,10 @@ For tutorial Markdown files, you can either:
 - Save the file in a directory with the product documentation.
 - Create a subfolder under `doc/tutorials` and name the file `index.md`.
 
+In the left nav, add the tutorial near the relevant feature documentation.
+
+Add a link to the tutorial on one of the [tutorial pages](../../../tutorials/index.md).
+
 ## Tutorial format
 
 Tutorials should be in this format:
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 95f0692c3e6..dd417d038cb 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -278,6 +278,27 @@ to be longer. Some methods for shortening a name that's too long:
   `index_vulnerability_findings_remediations_on_remediation_id`.
 - Instead of columns, specify the purpose of the index, such as `index_users_for_unconfirmation_notification`.
 
+### Migration timestamp age
+
+The timestamp portion of a migration filename determines the order in which migrations
+are run. It's important to maintain a rough correlation between:
+
+1. When a migration is added to the GitLab codebase.
+1. The timestamp of the migration itself.
+
+A new migration's timestamp should *never* be before the previous hard stop.
+Migrations are occasionally squashed, and if a migration is added whose timestamp
+falls before the previous hard stop, a problem like what happened in
+[issue 408304](https://gitlab.com/gitlab-org/gitlab/-/issues/408304) can occur.
+
+For example, if we are currently developing against GitLab 16.0, the previous
+hard stop is 15.11. 15.11 was released on April 23rd, 2023. Therefore, the
+minimum acceptable timestamp would be 20230424000000.
+
+#### Best practice
+
+While the above should be considered a hard rule, it is a best practice to try to keep migration timestamps to within three weeks of the date it is anticipated that the migration will be merged upstream, regardless of how much time has elapsed since the last hard stop.
+
 ## Heavy operations in a single transaction
 
 When using a single-transaction migration, a transaction holds a database connection