Fixing some links

docs/03-Hermes/01-Hermes.md

@@ -18,8 +18,7 @@ The goal of the Hermes project is to provide a *seamless* solution that
 utilizes DDSH without or requiring only minor application changes.
 
 (Even without a deep DDSH, determined users have created original
-solutions to overcome I/O performance challenges. See [use
-cases](Use-Cases) for an example. Many of them can be
+solutions to overcome I/O performance challenges. See use cases for an example. Many of them can be
 considered custom, i.e., application-specific, I/O buffering systems.)
 
 # How We Do It
@@ -37,8 +36,7 @@ with the following characteristics:
     is reached, the buffering system can no longer deliver noticeable
     benefits and may perform as poorly as (or worse) than the unbuffered
     system (going to PFS).
-  - Users express I/O priorities, constraints, and hints via [buffering
-    policies](Policies).
+  - Users express I/O priorities, constraints, and hints via buffering policies.
   - Given individual or batches of I/O operations (writes and reads),
     the **main challenge** for such a buffering system is to determine
     where in DDSH a given data item is <b>best/well/optimally-</b>placed at
@@ -53,13 +51,13 @@ with the following characteristics:
         target](06-Hermes-components/03-Buffering-Target.md)s and are applicable more
         broadly.
       - The physical buffering resources are managed in a distributed
-        [buffer pool](06-Hermes-components/02-Buffer-Pool.md) (see also [Batching
-        System](Batching-System)).
+        [buffer pool](06-Hermes-components/02-Buffer-Pool.md) (see also Batching
+        System).
       - [Buffer Organizer](06-Hermes-components/01-Buffer-Organizer.md)
-      - [Profiler](./Profiler)
+      - Profiler
       - To separate concerns and for portability, system buffers are
         **not** directly exposed to applications. There is a set of
-        intermediate [primitives](Primitives) targeted by
+        intermediate primitives targeted by
         [adapters](./Adapters) for different I/O libraries. A
         generic [metadata manager](06-Hermes-components/08-Metadata-Manager.md) (MDM),
         supports the bookkeeping needs of the various components.

docs/03-Hermes/07-Adapters/01-Adapters.md

@@ -1,6 +1,6 @@
 [[../images/Hermes_Ecosystem.jpg|Hermes Adapters]]
 
-Instead of the [Hermes primitives](Primitives), existing applications
+Instead of the [Hermes primitives](../03-Hermes/05-Basic-programming/01-Basic-Programming), existing applications
 use I/O libraries and middleware such as the C standard I/O library,
 MPI-IO, or HDF5. Since Hermes is intended to be a seamless I/O
 buffering solution, a set of *adapters* is provided in the form of

docs/03-Hermes/09-Developers-Guide/01-Developers-Guide.md

@@ -54,13 +54,13 @@ The cache does not have to change often (unless you've added dependencies),
 so this should be done only in this case. To refresh the github cache,
 modify the file "ci/install_deps.sh" in some way. For
 example, by adding a comment. If you check the [github workflow which produces
-the cache](../blob/master/.github/workflows/main.yml), it uses a hash
+the cache](https://github.com/HDFGroup/hermes/blob/master/.github/workflows/main.yml), it uses a hash
 of install_deps.sh to locate a cache.
 
 # Introduction to our Continuous Integration (CI)
 
 We are primarily using Python for managing for running unit tests. Under
-[our root CMakeList](../blob/master/CMakeLists.txt), we implement a
+[our root CMakeList](https://github.com/HDFGroup/hermes/blob/master/CMakeLists.txt), we implement a
 CMake function called pytest, which wraps around the Python testing
 framework called py_hermes_ci, which is located under ci/py_hermes_ci.