Update glossary (#2184)

* Update glossary to docusaurus style

* Add backward compatible anchors

* Add missing #

* Restore alphabetical ordering

* Copy editing

* Fix links

* Remove explicit anchor tags

* Re-introduce html anchors for stability

* Update links to new docusaurus format

* Re-add title frontmatter

* Re-add pypackaging link

* Clarify CDTs

* Improve CLI explanation

* Urlencode ling to avoid <> syntax

Author: zklaus

docs/glossary.md

@@ -1,6 +1,5 @@
 ---
 title: 'Glossary'
-sidebar_position: 27
 ---
 
 <a id="miscellaneous"></a>
@@ -11,74 +10,116 @@ sidebar_position: 27
 
 # Glossary
 
+List of frequently used terms and acronyms.
+
 <a id="term-ABI"></a>
 
 ## ABI
 
-**A**pplication **B**inary **I**nterface. ABI is a document that comprehensively defines the binary system interface between applications and the operating system on which they run. [Learn More at Wikipedia](https://en.wikipedia.org/wiki/Application_binary_interface) or [pypackaging-native](https://pypackaging-native.github.io/background/binary_interface).
+Application Binary Interface. ABI is a document that comprehensively defines the binary system interface between applications and the operating system on which they run.
+
+Learn More at [Wikipedia](https://en.wikipedia.org/wiki/Application_binary_interface) or [pypackaging-native](https://pypackaging-native.github.io/background/binary_interface).
+
+<a id="term-CDN"></a>
+
+## CDN
+
+Content Delivery Network. CDNs are geographically distributed networks of servers that mirror the contents of a primary source. Having multiple servers offering the same content increases performance (reduced latency, higher download speeds) and availability.
+
+[Learn more](https://en.wikipedia.org/wiki/Content_delivery_network).
 
 <a id="term-CDT"></a>
 
 ## CDT
 
-**C**ore **D**ependency **T**ree. Core Dependency Tree packages take care of the dependencies which are so close to the system that they are not packaged with conda-forge. A CDT package consists of repackaged CentOS binaries from the appropriate version, either 6 or 7 depending on user choice and platform. [Learn more](maintainer/knowledge_base.md#cdt-packages).
+Core Dependency Tree. Core Dependency Tree packages take care of the dependencies that are so close to the system that they are not packaged with conda-forge. For example, in conda-forge, we have used repackaged CentOS 6 or 7 binaries for some time.
 
-## CLI
+[Learn more](https://conda-forge.org/docs/maintainer/knowledge_base.html#cdt-packages).
 
-**C**ommand **L**ine **I**nterface. A program in which commands are entered as text, one line at a time, for a computer to execute. This is done in the Miniforge Prompt in Windows, and in a terminal in macOS and Linux. `conda` is executed in a CLI. [Learn More](https://en.wikipedia.org/wiki/Command-line_interface).
+<a id="term-CFEP"></a>
+
+## CFEP
+
+Conda Forge Enhancement Proposal. A CFEP is a document that outlines a suggested change to how the conda-forge project operates, from a technical standpoint as well as to address social topics such as governance and expected conduct.
+
+[Learn More](https://github.com/conda-forge/cfep/blob/main/cfep-01.md/).
 
 <a id="term-CI"></a>
 
 ## CI
 
-**C**ontinuous **I**ntegration. Continuous integration is the practice of automating the integration of code changes from multiple contributors into a single software project. [Learn More](https://en.wikipedia.org/wiki/Continuous_integration).
+Continuous Integration. Continuous integration is the practice of automating the integration of code changes from multiple contributors into a single software project.
 
-<a id="term-CFEP"></a>
+[Learn More](https://en.wikipedia.org/wiki/Continuous_integration).
 
-## CFEP
+<a id="term-CLI"></a>
 
-**C**onda **F**orge **E**nhancement **P**roposal. A CFEP is a document which outlines a suggested change to how the conda-forge project operates, from a technical standpoint as well as to address social topics such as governance and expected conduct. [Learn More](https://github.com/conda-forge/cfep/blob/main/cfep-01.md/).
+## CLI
+
+Command Line Interface. A textual interface of a program that allows the user to control the program with a single command line, which is entered in a command-line environment, such as the Miniforge Prompt on Windows, or a terminal on MacOS and Linux. An example of a program offering a CLI is `conda`.
+
+[Learn More](https://en.wikipedia.org/wiki/Command-line_interface).
 
 <a id="term-Conda-channel"></a>
 
 ## Conda channel
 
-Conda channels are the locations where packages are stored. They serve as the base for hosting and managing packages. `conda-forge` is one example of a conda channel. [Learn More](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/channels.html).
+Conda channels are the locations where packages are stored. They serve as the base for hosting and managing packages. `conda-forge` is one example of a conda channel.
+
+[Learn More](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/channels.html).
 
 <a id="term-Conda-package"></a>
 
 ## Conda package
 
-A conda package is a `.tar.bz2` or `.conda` archive that contains libraries, executable programs, data files and other components, as well as metadata under the `info/` directory. Its contents are unpacked in the installation prefix. [Learn More](<https://en.wikipedia.org/wiki/Conda_(package_manager)>).
+A conda package is a `.tar.bz2` or `.conda` archive that contains libraries, executable programs, data files and other components, as well as metadata under the `info/` directory. Its contents are unpacked in the installation prefix.
+
+[Learn More](https://en.wikipedia.org/wiki/Conda_%28package_manager%29).
 
 <a id="term-CRAN"></a>
 
 ## CRAN
 
-**C**omprehensive **R** **A**rchive **N**etwork. CRAN is a network of FTP and web servers around the world that store identical, up-to-date, versions of code and documentation for R. [Learn More](https://cran.r-project.org/).
+Comprehensive R Archive Network. CRAN is a network of FTP and web servers around the world that store identical, up-to-date versions of code and documentation for R.
+
+[Learn More](https://cran.r-project.org/).
 
 <a id="term-Environment"></a>
 
 ## Environment
 
-An environment is a tool that helps to keep dependencies required by different projects separate by creating isolated spaces where these dependencies are installed. [Learn More](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/environments.html).
+An environment is a tool that helps to keep dependencies required by different projects separate by creating isolated spaces where these dependencies are installed.
+
+[Learn More](https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/environments.html).
 
 <a id="term-ICU"></a>
 
 ## ICU
 
-**I**nternational **C**omponents for **U**nicode. ICU is an open-source project of mature C/C++ and Java libraries for Unicode support, software internationalization, and software globalization. [Learn More](https://icu.unicode.org/).
+International Components for Unicode. ICU is an open-source project of mature C/C++ and Java libraries for Unicode support, software internationalization, and software globalization.
+
+[Learn More](https://icu.unicode.org/).
 
 <a id="term-PR"></a>
 
 ## PR
 
-**P**ull **R**equest. Pull Request is a workflow method to submit contributions to an open development project in which the developer asks for changes committed to an external repository to be considered for inclusion in a project's main repository. [Learn More](https://help.github.com/articles/about-pull-requests/).
+Pull Request. A Pull Request is a workflow method to submit contributions to an open development project in which the developer asks for changes committed to an external repository to be considered for inclusion in a project's main repository.
+
+[Learn More](https://help.github.com/articles/about-pull-requests/).
+
+<a id="term-Recipe"></a>
 
 ## Recipe
 
-A recipe is a collection of files required to build a conda package. This includes, at minimum, a [`meta.yaml`](maintainer/adding_pkgs.md#the-recipe-meta-yaml) file, but can also include license files, patches, build scripts, test scripts etc. [Learn More](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html).
+A recipe is a collection of files required to build a conda package. This includes, at minimum, a [`meta.yaml`](maintainer/adding_pkgs.md#the-recipe-meta-yaml) file, but can also include license files, patches, build scripts, test scripts etc.
+
+[Learn More](https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html).
+
+<a id="term-Virtual-package"></a>
 
 ## Virtual package
 
-Virtual packages are not real packages that can be downloaded. They are injected by the conda clients at runtime so the solver can consider that metadata as part of the constraints of the problem. By convention, they always start with a double underscore (`__`). Some examples include the type of operating system (Linux, Windows, macOS), or the CUDA version supported by the system (if any). [Learn More](https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-virtual.html).
+Virtual packages are not real packages that can be downloaded. They are injected by the conda clients at runtime so the solver can consider that metadata as part of the constraints of the problem. By convention, they always start with a double underscore (`__`). Some examples include the type of operating system (Linux, Windows, macOS), or the CUDA version supported by the system (if any).
+
+[Learn More](https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-virtual.html).

docs/maintainer/adding_pkgs.md

@@ -134,7 +134,7 @@ Once you finished your PR, all you have to do is wait for feedback from our revi
 
 The review team will assist you by pointing out improvements and answering questions. Once the package is ready, the reviewers will approve and merge your pull request.
 
-After merging the [PR](../glossary.md#term-PR), our [CI](../glossary.md#term-CI) infrastructure will build the package and make it available in the conda-channel.
+After merging the [PR](../glossary.md#pr), our [CI](../glossary.md#ci) infrastructure will build the package and make it available in the conda-channel.
 
 :::note
 
@@ -148,10 +148,10 @@ If you have questions or have not heard back for a while, you can notify us by i
 
 ## Post staging process
 
-- After the PR is merged, our [CI](../glossary.md#term-CI) services will create a new git repo automatically. For example, the recipe for a package named `pydstool` will be moved to a new repository [https://github.com/conda-forge/pydstool-feedstock](https://github.com/conda-forge/pydstool-feedstock). This process is automated through a CI job on the `conda-forge/staged-recipes` repo. It sometimes fails due to API rate limits and will automatically retry itself. If your feedstock has not been created after a day or so, please get in touch with the `conda-forge/core` team for help.
+- After the PR is merged, our [CI](../glossary.md#ci) services will create a new git repo automatically. For example, the recipe for a package named `pydstool` will be moved to a new repository [https://github.com/conda-forge/pydstool-feedstock](https://github.com/conda-forge/pydstool-feedstock). This process is automated through a CI job on the `conda-forge/staged-recipes` repo. It sometimes fails due to API rate limits and will automatically retry itself. If your feedstock has not been created after a day or so, please get in touch with the `conda-forge/core` team for help.
 - CI services will be enabled automatically and a build will be triggered automatically which will build the conda package and upload to [https://anaconda.org/conda-forge](https://anaconda.org/conda-forge)
 - If this is your first contribution, you will be added to the conda-forge [team](https://github.com/orgs/conda-forge/people) and given access to the CI services so that you can stop and restart builds. You will also be given commit rights to the new git repository.
-- If you want to make a change to the recipe, send a [PR](../glossary.md#term-PR) to the git repository from a fork. Branches of the main repository are used for maintaining different versions only.
+- If you want to make a change to the recipe, send a [PR](../glossary.md#pr) to the git repository from a fork. Branches of the main repository are used for maintaining different versions only.
 
 <a id="feedstock-repository-structure"></a>
 
@@ -196,7 +196,7 @@ This file is used to configure how the feedstock is set up and built. Making any
 
 The maintainer's job is to:
 
-- Keep the feedstock updated by merging eventual maintenance [PR](../glossary.md#term-PR)s from conda-forge's bots.
+- Keep the feedstock updated by merging eventual maintenance [PR](../glossary.md#pr)s from conda-forge's bots.
 - Keep the feedstock on par with new releases of the source package by:
   - Bumping the version number and checksum.
   - Making sure that the feedstock's requirements stay accurate.
@@ -452,26 +452,26 @@ Run dependencies are only required during run time of the package. Run dependenc
 
 #### Avoid external dependencies
 
-As a general rule: all dependencies have to be packaged by conda-forge as well. This is necessary to assure [ABI](../glossary.md#term-ABI) compatibility for all our packages.
+As a general rule: all dependencies have to be packaged by conda-forge as well. This is necessary to assure [ABI](../glossary.md#abi) compatibility for all our packages.
 
 There are only a few exceptions to this rule:
 
-1. Some dependencies have to be satisfied with [CDT](../glossary.md#term-CDT) packages (see [Core Dependency Tree Packages (CDTs)](knowledge_base.md#cdt-packages)).
+1. Some dependencies have to be satisfied with [CDT](../glossary.md#cdt) packages (see [Core Dependency Tree Packages (CDTs)](knowledge_base.md#cdt-packages)).
 2. Some packages require root access (e.g. device drivers) that cannot be distributed by conda-forge. These dependencies should be avoided whenever possible.
 
 <a id="pinning"></a>
 
 #### Pinning
 
-Linking shared c/c++ libraries creates dependence on the [ABI](../glossary.md#term-ABI) of the library that was used at build time on the package.
+Linking shared c/c++ libraries creates dependence on the [ABI](../glossary.md#abi) of the library that was used at build time on the package.
 The exposed interface changes when previously existing exposed symbols are deleted or modified in a newer version.
 
-It is therefore crucial to ensure that only library versions with a compatible [ABI](../glossary.md#term-ABI) are used after linking.
+It is therefore crucial to ensure that only library versions with a compatible [ABI](../glossary.md#abi) are used after linking.
 
 In the best case, the shared library you depend on:
 
 - defines a pin in the [list of globally pinned packages](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml)
-- exports its [ABI](../glossary.md#term-ABI) compatible requirements by defining `run_exports` in it's meta.yaml
+- exports its [ABI](../glossary.md#abi) compatible requirements by defining `run_exports` in it's meta.yaml
 
 In these cases you do not have to worry about version requirements:
 
@@ -483,7 +483,7 @@ requirements:
     - libpng
 ```
 
-In other cases you have to specify [ABI](../glossary.md#term-ABI) compatible versions manually.
+In other cases you have to specify [ABI](../glossary.md#abi) compatible versions manually.
 
 ```yaml
 requirements:
@@ -555,7 +555,7 @@ But every conda package must have at least _some_ tests.
 Sometimes defining tests seems to be hard, e.g. due to:
 
 - tests for the underlying code base may not exist.
-- test suites may take too long to run on limited [CI](../glossary.md#term-CI) infrastructure.
+- test suites may take too long to run on limited [CI](../glossary.md#ci) infrastructure.
 - tests may take too much bandwidth.
 
 In these cases, conda-forge may not be able to execute the prescribed test suite.

docs/maintainer/infrastructure.md

@@ -161,7 +161,7 @@ Package-wide dependency pins are defined in [conda_build_config.yaml](https://gi
 
 For more information on conda-forge wide package pins, please refer to [Globally pinned packages](pinning_deps.md#globally-pinned-packages).
 
-Please open a [PR](../glossary.md#term-PR) and/or an issue there, if you think a pin needs to be advanced. For more information on updating globally pinned packages, please refer to [Updating package pins](pinning_deps.md#update-pins).
+Please open a [PR](../glossary.md#pr) and/or an issue there, if you think a pin needs to be advanced. For more information on updating globally pinned packages, please refer to [Updating package pins](pinning_deps.md#update-pins).
 
 #### conda-forge-repodata-patches
 
@@ -226,7 +226,7 @@ Smithy contains maintenance code for conda-forge, which is used by the `conda-sm
 
 - The rerendering process
 - The recipe linter
-- [CI](../glossary.md#term-CI) support utils
+- [CI](../glossary.md#ci) support utils
 
 `conda-smithy` also contains the command line tool that you should use if you rerender manually from the command line (see [Rerendering feedstocks](updating_pkgs.md#dev-update-rerender)).
 

docs/maintainer/knowledge_base.md

@@ -1170,7 +1170,7 @@ named `yum_requirements.txt` in the `recipe` directory of a feedstock.
 
 There are only very few situations where dependencies installed by yum are acceptable. These cases include
 
-- satisfying the requirements of [CDT](../glossary.md#term-CDT) packages during test phase
+- satisfying the requirements of [CDT](../glossary.md#cdt) packages during test phase
 - installing packages that are only required for testing
 
 After changing `yum_requirements.txt`, [rerender](updating_pkgs.md#dev-update-rerender) to update the configuration.

docs/maintainer/pinning_deps.md

@@ -84,7 +84,7 @@ There is additional documentation on this pinning scheme in [the conda docs](htt
 
 ## Specifying run_exports
 
-The `run_exports` feature can be used to specify the versions that are [ABI](../glossary.md#term-ABI) compatible with the built version. This leads to higher flexibility of choosable packages, without breakages due to incompatibilities.
+The `run_exports` feature can be used to specify the versions that are [ABI](../glossary.md#abi) compatible with the built version. This leads to higher flexibility of choosable packages, without breakages due to incompatibilities.
 
 Packages that depend on a package with `run_exports` can choose to overwrite this behavior using the `build/ignore_run_exports` key.
 
@@ -123,7 +123,7 @@ be added by hand. To do this, follow these steps:
 1. Create a new migration yaml by copying [example.exyaml](https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/migrations/example.exyaml) in the `conda-forge/conda-forge-pinning` repository.
 2. Change the migration yaml to reflect the package and version to be migrated
 3. Write a migrator for propagating the pin changes.
-4. Propose the changes as a [PR](../glossary.md#term-PR) to [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).
+4. Propose the changes as a [PR](../glossary.md#pr) to [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock).
 5. Once accepted the migration will begin. The migration status can be monitored at [https://conda-forge.org/status](https://conda-forge.org/status).
 6. After the migration is complete, a new PR can be issued to [conda-forge/conda-forge-pinning-feedstock](https://github.com/conda-forge/conda-forge-pinning-feedstock) to:
    - Remove the migrator yaml for the completed migration