diff --git a/docs/references/legacy.md b/docs/references/legacy.md
index 6b7a20f036f016f0799bfffff826b7ed47992c1a..7d14f84babded66768debed4b949cf7dff81c2e6 100644
--- a/docs/references/legacy.md
+++ b/docs/references/legacy.md
@@ -111,7 +111,7 @@ connect gem-shelfXX-amcYY
rwc GEM_AMC.OH_LINKS.OH*GBT*READY
```
-The configurations files with the correct GBT phases used for the configuration of the detector are `$DATA_PATH/config/gbt/gem-shelfXX-amcYY-phases.txt`. Update the files with the newest values of the phases, tracking the differences between the previous version and the new one, if needed (relevant changes are if the phase is/was set to 15 or if it is shifted by 3/4 units). If VFAT and GBT communication statuses are different, they should be traked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
+The configurations files with the correct GBT phases used for the configuration of the detector are `$DATA_PATH/config/gbt/gem-shelfXX-amcYY-phases.txt`. Update the files with the newest values of the phases, tracking the differences between the previous version and the new one, if needed (relevant changes are if the phase is/was set to 15 or if it is shifted by 3/4 units). If VFAT and GBT communication statuses are different, they should be traked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
#### Taking the DAC scans
@@ -123,7 +123,7 @@ for i in {0..11}; do getCalInfoFromDB.py XX YY $i --write2File --write2CTP7; don
~/scripts/testConnectivity.py --gemType ge11 --detType=short XX YY 0xfff -a --skipGBTPhaseScan --acceptBadDACFits --skipScurve -i -f5
```
-The output files should be inspected and any result that could indicate a broken DAC circuit should be reported in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
+The output files should be inspected and any result that could indicate a broken DAC circuit should be reported in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
### Data-taking procedures
@@ -175,7 +175,8 @@ for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<s
for l in 1 2; do for i in {01..36}; do cp $DATA_PATH/GE11-M-${i}L${l}*/scurve/<symlink>/SCurveData/h2ScurveSigmaDist_All.png /nfshome0/gempro/elog/<my_name>/h2ScurveSigmaDist_All_GE11-M-${i}L${l}.png; done; done
```
-Any discrepancy between the results and what expected from the configuration, i.e. the scans or the analysis failing for a part of the detector, should be investigated and tracked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-online-support/-/issues).
+Any discrepancy between the results and what expected from the configuration, i.e. the scans or the analysis failing for a part of the detector, should be investigated and tracked in the [GitLab issues](https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-issue-tracker/-/issues).
+
#### Checking the HV mapping
Checking the HV mapping is one of the last checks to be performed once the front-end communication has been established and the frontend status confirmed. The HV training must be completed as well since signal amplification is required in the chambers.
diff --git a/docs/setups-description.md b/docs/setups-description.md
index a8b026b81c08483f6c64610b5b6e44277774bd0e..72fea24a1dc45b248b4952079fafcb2b07e88f52 100644
--- a/docs/setups-description.md
+++ b/docs/setups-description.md
@@ -183,26 +183,3 @@ But the setup should *always* be left in a usable state for the next user.
Moreover, if you are not on the list of approved individuals who can modify the hardware/stand infrastructure you should not (if you are wondering if you are on this list it probably means you are *not*).
Failure to follow these rules makes more work for the DAQ expert team, setup responsible/sysadmin.
-
-### Requesting time on GEM setups
-
-Each setup has its own requisition page on SuperSaaS to manage testing and ensure we do not collide with other users.
-To see the available setups and to request time on navigate to:
-
-<https://www.supersaas.com/schedule/GEM_Infrastructure>
-
-Before trying to modify the above schedules you'll need to first ask for the GEM Infrastructure shared password on SuperSaaS to use the scheduling tools.
-To do this ask one of the DAQ expert, setup responsible/sysadmin.
-
-When scheduling you need to provide:
-
-- Your name
-- Your email
-- Estimated time your test will take (starting & ending time)
-- Description of your test
-
-Your request will be submitted and then approved.
-
-!!! note
- Any non-overlaping request is considered as immediately approved and you can start using the stand.
- In case of long or overlaping requests, please contact the setup responsible.
diff --git a/mkdocs.yml b/mkdocs.yml
index a8ad2de176f8ae3017ee86c917aff8643eb46e28..f23882964ad72ad5c26a9a5e1ab64255551c9398 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -1,7 +1,7 @@
-site_name: CMS GEM DAQ Documentation
+site_name: CMS GEM Documentation
site_url: https://cmsgemonline.web.cern.ch/doc/latest
-repo_url: https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-daq-doc
+repo_url: https://gitlab.cern.ch/cmsgemonline/gem-ops/gem-documentation
repo_name: GitLab
edit_uri: edit/main/docs/