Remove newuserdocs page (moved to internal HQ documentation)

general/development/process/release/index.md

@@ -55,15 +55,15 @@ sidebar_position: 7
 | 5. | &#10003; |  | Release candidates release (The Moodle release tool - `mdlrelease` - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:<ul><li>`version.php`: Move to `$maturity = MATURITY_RC` and `$release = 'X.YrcZ (Build:xxxxxxxx)'`</li><li>tag git repo with: `vX.Y.0-rcZ` (and `MOODLE_XY_RCZ` as description and Git tag)</li><li>Automatic: Confirm packages are available under [download.moodle.org](https://download.moodle.org) (and windows).</li><li>Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.</li></ul> | Integration Team |
 | 6. | &#10003; |  | Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).<ul><li>Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.</li><li>These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512</li></ul> | Plugins Liaison |
 | 7. | &#10003; |  | Push any plugins to the plugins database which were previously a part of core. | Plugins Liaison |
-| 8. | &#10003; |  | Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [New docs version process](./newuserdocs.md). | Community Manager |
+| 8. | &#10003; |  | Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki. | Community Manager |
 
 ## 3 weeks prior {/* #3-weeks-prior */}
 
 | # | Major | Minor | Task | Responsibility |
 | :---: | :---: | :---: | --- | --- |
 | 1. | &#10003; |  | Ask developers to begin QA tests marked [`external_skipped`](https://moodle.atlassian.net/issues/?filter=22055) then [`test_server_required` tests](https://moodle.atlassian.net/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20test_server_required%20) and [`credentials_required` tests](https://moodle.atlassian.net/issues/?filter=22055&jql=filter%20%3D%20%22Current%20QA%20cycle%20filter%22%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20credentials_required). | Product delivery lead |
 | 2. | &#10003; |  | Create new en and de Moodle Docs version wikis. | Moodle Docs Maintainer |
-| 3. | &#10003; |  | Go through all points listed under 3 weeks prior in [New docs version process](./newuserdocs.md). | Community Manager |
+| 3. | &#10003; |  | Continue the Moodle Docs new version setup: 3 weeks prior tasks. | Community Manager |
 | 4. | &#10003; |  | Review issues with labelled with [`dev_docs_required`](https://moodle.atlassian.net/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC), prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated. | Product delivery lead |
 | 5. | &#10003; | &#10003; | Organise a meeting to verify how everything is going and, before the end of the week, decide (dev leaders from Platform, Educational solutions, Cloud, Apps, Workplace & integrators) if there are real reasons for delaying any release. Whenever a delay is agreed, run the *"Release delaying process"* (doc) actions ASAP.<br/><br/>**Important note**: ASAP stands for as soon as possible ;-), the delay needs to happen before the last week before release begins (there are flows changing that week requiring the decision and actions to be taken and applied earlier) | Product delivery lead |
 
@@ -96,7 +96,7 @@ sidebar_position: 7
 | 11. | &#10003; |  | Organise a meeting to review the following issues: <ul><li>Check on the [`Must fix for X.Y version`](https://moodle.atlassian.net/issues/?filter=21363). Filter out unrealistic issues.</li><li>Check on the ["Bug issues held last week before release"](https://moodle.atlassian.net/issues/?filter=22350). Consider to request the un-holding of release related/blocker ones.</li></ul> | Product delivery lead |
 | 12. | &#10003; |  | Have the community team update the following (in order) to beta release: <ul><li>the [demo sites](https://moodle.org/demo)</li><li>[moodle.org](https://moodle.org/)</li></ul> | Community Manager |
 | 13. | &#10003; |  | Prepare pull requests for CI Repositories:<ul><li>`MR1`: Create a new version, with unit tests, in Jobs repository ([see example from 4.5 release](https://git.in.moodle.com/integration/nightlyjobs/-/merge_requests/62))</li><li>`MR2`: Create a new symlink for the version in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository ([see example from 4.5 release](https://github.com/moodlehq/moodle-ci-runner/pull/131))</li><li>`MR3`: Configure CIs to skip language upgrade in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository ([see example from 4.5 release](https://github.com/moodlehq/moodle-ci-runner/pull/132))</li><li>`MR4`: Configure CIs to stop skipping language upgrade in [moodle-ci-runner](https://github.com/moodlehq/moodle-ci-runner) repository for after on-sync ([see example from 4.5 release](https://github.com/moodlehq/moodle-ci-runner/pull/133)) -- **Note**: This change should be based on the previous and only applied when the lang packs corresponding to the NEXT version (X.Y+1) are available.</li></ul> | Integration Team |
-| 14. | &#10003; |  | Go through all points listed under 1 week prior in [New docs version process](./newuserdocs.md). | Community Manager |
+| 14. | &#10003; |  | Continue the Moodle Docs new version setup: 1 week prior tasks. | Community Manager |
 | 15. | &#10003; |  | Update the `BRANCHLIST` and `VERSIONLIST` in the [JSDoc](https://github.com/moodle/jsdoc) and [PHPDoc](https://github.com/moodle/phpdoc) repositories with the list of supported versions. These are built on a Sunday so this should be done in the final week before release. | Integration Team |
 
 ## Releasing {/* #releasing */}
@@ -146,7 +146,7 @@ Usually on Monday
 | 8. | &#10003; |  | Add the next branch code to the `branchesall` admin setting at lang.moodle.org. Review the list of supported versions and update the value of `branchsupported` there eventually, too.  | AMOS Maintainer |
 | 9. | &#10003; | &#10003; | Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent `MDLSITE` issue, crons must be running! | Integration Team |
 | 10. | &#10003; |  | For `en` and `de` Moodle Docs, update default redirects and enable email notifications. | Moodle Docs Maintainer |
-| 11. | &#10003; |  | Go through all points listed under Day of release in [New docs version process](./newuserdocs.md). | Community Manager |
+| 11. | &#10003; |  | Continue the Moodle Docs new version setup: Day of release tasks. | Community Manager |
 | 12. | &#10003; |  | <ul><li>Decide the `Full demo`, `Code freeze` and `QA begins` dates for the next `X.(Y+1)` major release and put them in the [Moodle development calendar](https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics). They will be -7w, -5w and -5w before release date respectively.</li><li>Update the `Full demo`, `Code freeze`, `QA begins` and `Release` dates on the Roadmap page.</li><li>Notify the Community Manager of new dates to be added to the moodle.org calendar.</li></ul> | Product delivery lead |
 | 13. | &#10003; | | Add calendar events in the [moodle.org calendar](https://moodle.org/calendar) for coming Major and Minor releases up to the next Major release. | Community Manager |
 | 14. | &#10003; | &#10003; | Update release schedule image on [Releases page](../../../releases.md#version-support) | Platform Manager |