[Docs] Update release docs (#7902)

wiki/eui-team-processes/releasing-versions.md

@@ -105,7 +105,7 @@ If it's possible to avoid a backport by performing a full release or patch relea
       * You may need to re-run yarn in order to commit changes, if the commit modified dependencies
       * Remember to continue cherry picking with `git cherry-pick --continue` until all commits have been applied
 * Start the dev server and check that the intended changes have been properly applied, you don't want to repeat this process to patch the patch - `yarn start`
-* Once everything looks correct, it's time to [release](https://github.com/elastic/eui/blob/main/scripts/release.js):
+* Once everything looks correct, it's time to [release](https://github.com/elastic/eui/blob/main/packages/eui/scripts/release.js):
   * `npm run release-backport`
 * Update Kibana's `package.json` to point at the newly-released backport, e.g. `"@elastic/eui": "90.0.0-backport.0"`
 
@@ -120,7 +120,7 @@ The prerelease process is very similar to the backport process above.
   - Otherwise, simply check out the [latest EUI release](https://github.com/elastic/eui/releases), e.g. `git checkout v83.0.0`
   - The purpose of this step (instead of releasing from latest `main`) is to reduce as much noise as possible and ensure you're *only* testing the changes you want to test. This is particularly necessary for Kibana CI testing.
 - Apply the commit(s) with the desired changes, e.g. `git cherry-pick [commit-id]`
-- Once everything looks correct, it's time to [release](https://github.com/elastic/eui/blob/main/scripts/release.js):
+- Once everything looks correct, it's time to [release](https://github.com/elastic/eui/blob/main/packages/eui/scripts/release.js):
   * `npm run release-rc`
 - Go to https://www.npmjs.com/package/@elastic/eui?activeTab=versions and confirm that your pre-release has been pushed up with the correct version and tag, e.g. `83.1.1-rc.0`
 - Update Kibana or CodeSandbox (or whatever other environment you are using to test) to point at that version

wiki/eui-team-processes/upgrading-kibana.md

@@ -19,7 +19,7 @@
 
 ### i18n updates
 
-Check whether the target version upgrade range [contains i18n token changes](https://github.com/elastic/eui/blob/main/i18ntokens_changelog.json).
+Check whether the target version upgrade range [contains i18n token changes](https://github.com/elastic/eui/blob/main/packages/eui/i18ntokens_changelog.json).
 
 If changes exist:
 
@@ -41,12 +41,14 @@ If it's too much effort for the EUI team alone to handle migrating/updating depr
 
 At this point, we recommend opening a **draft** PR with your existing commits/changes against Kibana main. Unfortunately, Kibana's many tests are far too numerous to reasonably run them all locally - your machine will OOM if you even try. Kicking off a CI run is therefore the quickest way to find test failures at this point.
 
+Draft PRs in Kibana do not start CI automatically - you'll need to manually comment `/ci` in GitHub to kick off a run.
+
 ### PR template
 
 The typical EUI upgrade PR in Kibana looks something like [#109157](https://github.com/elastic/kibana/pull/109157), and reviewers have begun to expect the consistency. There are two important inclusions:
 
 * Call out changes made to accommodate test failures that might not be apparent from looking at the diff.
-* Copy-paste the full changelog version range [from the latest changelog file](https://github.com/elastic/eui/blob/main/changelogs) for the upgrade.
+* Copy-paste the full changelog version range [from the latest changelog file](https://github.com/elastic/eui/tree/main/packages/eui/changelogs) for the upgrade.
 
 Labels to use: