Merge pull request #3099 from eduartua/issue-3064-2

File moved (k/community/contributors/devel/collab.md) - Created tombstone file and updated URL in other files

5 files changed, 40 insertions, 37 deletions

diff --git a/community-membership.md b/community-membership.md
index 91467b99..7d85360d 100644
--- a/community-membership.md
+++ b/community-membership.md
@@ -223,7 +223,7 @@ The following apply to the subproject for which one would be an owner.
 
 The Maintainer role has been removed and replaced with a greater focus on [OWNERS].
 
-[code reviews]: /contributors/devel/collab.md
+[code reviews]: /contributors/guide/collab.md
 [community expectations]: /contributors/guide/community-expectations.md
 [contributor guide]: /contributors/guide/README.md
 [Kubernetes GitHub Admin team]: /github-management/README.md#github-administration-team
diff --git a/contributors/devel/collab.md b/contributors/devel/collab.md
index 73ddebb9..62cb85eb 100644
--- a/contributors/devel/collab.md
+++ b/contributors/devel/collab.md
@@ -1,35 +1,3 @@
-# On Collaborative Development
+This document has moved to: [here](https://git.k8s.io/community/contributors/guide/collab.md).
 
-## Code reviews
-
-All changes must be code reviewed. For non-maintainers this is obvious, since
-you can't commit anyway. But even for maintainers, we want all changes to get at
-least one review, preferably (for non-trivial changes obligatorily) from someone
-who knows the areas the change touches. For non-trivial changes we may want two
-reviewers. The primary reviewer will make this decision and nominate a second
-reviewer, if needed. Except for trivial changes, PRs should not be committed
-until relevant parties (e.g. owners of the subsystem affected by the PR) have
-had a reasonable chance to look at PR in their local business hours.
-
-Most PRs will find reviewers organically. If a maintainer intends to be the
-primary reviewer of a PR they should set themselves as the assignee on GitHub
-and say so in a reply to the PR. Only the primary reviewer of a change should
-actually do the merge, except in rare cases (e.g. they are unavailable in a
-reasonable timeframe).
-
-If a PR has gone 2 work days without an owner emerging, please poke the PR
-thread and ask for a reviewer to be assigned.
-
-Except for rare cases, such as trivial changes (e.g. typos, comments) or
-emergencies (e.g. broken builds), maintainers should not merge their own
-changes.
-
-Expect reviewers to request that you avoid [common go style
-mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.
-
-## Assigned reviews
-
-Maintainers can assign reviews to other maintainers, when appropriate. The
-assignee becomes the shepherd for that PR and is responsible for merging the PR
-once they are satisfied with it or else closing it. The assignee might request
-reviews from non-maintainers.
+*This file is a redirect stub. It should be deleted within 3 months from the current date.*
\ No newline at end of file
diff --git a/contributors/guide/README.md b/contributors/guide/README.md
index 20c75be4..3ed78d07 100644
--- a/contributors/guide/README.md
+++ b/contributors/guide/README.md
@@ -159,7 +159,7 @@ If you find that this is not the case, please complain loudly.
 As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays.
 Please do not ever hesitate to ask a question or send a pull request.
 
-Check out our [community guiding principles](/contributors/devel/collab.md) on how to create great code as a big group.
+Check out our [community guiding principles](/contributors/guide/collab.md) on how to create great code as a big group.
 
 Beginner focused information can be found below in [Open a Pull Request](#open-a-pull-request) and [Code Review](#code-review).
 
diff --git a/contributors/guide/collab.md b/contributors/guide/collab.md
new file mode 100644
index 00000000..73ddebb9
--- /dev/null
+++ b/contributors/guide/collab.md
@@ -0,0 +1,35 @@
+# On Collaborative Development
+
+## Code reviews
+
+All changes must be code reviewed. For non-maintainers this is obvious, since
+you can't commit anyway. But even for maintainers, we want all changes to get at
+least one review, preferably (for non-trivial changes obligatorily) from someone
+who knows the areas the change touches. For non-trivial changes we may want two
+reviewers. The primary reviewer will make this decision and nominate a second
+reviewer, if needed. Except for trivial changes, PRs should not be committed
+until relevant parties (e.g. owners of the subsystem affected by the PR) have
+had a reasonable chance to look at PR in their local business hours.
+
+Most PRs will find reviewers organically. If a maintainer intends to be the
+primary reviewer of a PR they should set themselves as the assignee on GitHub
+and say so in a reply to the PR. Only the primary reviewer of a change should
+actually do the merge, except in rare cases (e.g. they are unavailable in a
+reasonable timeframe).
+
+If a PR has gone 2 work days without an owner emerging, please poke the PR
+thread and ask for a reviewer to be assigned.
+
+Except for rare cases, such as trivial changes (e.g. typos, comments) or
+emergencies (e.g. broken builds), maintainers should not merge their own
+changes.
+
+Expect reviewers to request that you avoid [common go style
+mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.
+
+## Assigned reviews
+
+Maintainers can assign reviews to other maintainers, when appropriate. The
+assignee becomes the shepherd for that PR and is responsible for merging the PR
+once they are satisfied with it or else closing it. The assignee might request
+reviews from non-maintainers.
diff --git a/mentoring/group-mentee-guide.md b/mentoring/group-mentee-guide.md
index 4a4c7d12..07ee17ba 100644
--- a/mentoring/group-mentee-guide.md
+++ b/mentoring/group-mentee-guide.md
@@ -70,7 +70,7 @@ Suggested Activity
 	- k/community is your friend for upstream workflows, processes, and information around contributing
 	- This repo includes the community/devel folder which will be extra helpful that includes docs such as:
     - [Code Review Expectations](/contributors/guide/community-expectations.md)
-    - [Collaboration on k8s](/contributors/devel/collab.md)
+    - [Collaboration on k8s](/contributors/guide/collab.md)
 
 
 ### Test Cohort Special Circumstances & Notes