Small changes to make things read better

docs/source/index.rst

@@ -1,34 +1,32 @@
-LASP Developer's Guide
-======================
-
 Welcome to the LASP Developer's Guide!
+======================================
 
 Purpose
 -------
 
-The purpose of this repository is to provide a collection of documented guidelines for software development workflows
-and processes commonly used within Data Systems in order to assist developers in accomplishing their work. The developer
-guide is managed within this version-controlled GitHub repository as to allow for the collaborative creation and
-maintenance of the guidelines.
+The purpose of this website is to provide a collection of documented guidelines for software development workflows and
+processes commonly used within Data Systems in order to assist developers in accomplishing their work. The developer
+guide is managed within a version-controlled `GitHub repository <https://github.com/lasp/developer-guide>`_ as to allow
+for the collaborative creation and maintenance of the guidelines.
 
 Motivation
 ----------
 
 The motivation for this effort is two-fold:
- - We are motivated by [Goal 3.1](https://confluence.lasp.colorado.edu/display/DS/2024-2027+Data+Systems+Strategic+Plan#id-20242027DataSystemsStrategicPlan-goal3)
-from the 2024-2027 Data Systems Strategic Plan, which states "Create a set of living DS best practices and training
-guides that include standard processes and expectations for common tasks".
- - With the push towards open science and access (see [NASA’s directive SPD-41a](https://science.nasa.gov/researchers/open-science/science-information-policy/))
-we hope to also embody this openness in our internal processes.
+ - We are motivated by `Goal 3.1 <https://confluence.lasp.colorado.edu/display/DS/2024-2027+Data+Systems+Strategic+Plan#id-20242027DataSystemsStrategicPlan-goal3>`_
+   from the 2024-2027 Data Systems Strategic Plan, which states "Create a set of living DS best practices and training
+   guides that include standard processes and expectations for common tasks".
+ - With the push towards open science and access (see `NASA’s directive SPD-41a <https://science.nasa.gov/researchers/open-science/science-information-policy>`_)
+   we hope to also embody this openness in our internal processes.
 
 Historically, such documentation has been spread over multiple pages and spaces within confluence and specific projects.
 The developer guide endeavors to bring these resources together in one centralized space, allowing for collaboration
 across individuals and teams. We can collectively determine "how we work best" and document such guidelines in a
 version-controlled repository with access to the collaborative tools that GitHub provides.
 
 Through this guide, we seek to promote a culture of continuous improvement, where feedback is encouraged, and processes
-are regularly reviewed and updated to reflect evolving industry standards and emerging technologies - this is a living
-document.
+are regularly reviewed and updated to reflect evolving industry standards and emerging technologies - these are a living
+documents!
 
 Another goal to provide an equal footing for all people, regardless of their background and skill levels. Having
 accessible, well-documented guidelines available to all people associated with the lab is a way to ensure all employees
@@ -44,8 +42,8 @@ Scope
 
 The developer guide aims to provide guidelines and recommendations, not mandates. It also aims to provide information
 in a non-redundant way, and avoid re-writing what may already be well-documented somewhere on the internet. Instead of
-describing a topic in detail, the developer guide attempts to answer the question -- "How do I apply this concept in the
-context of my work in Data Systems?"
+describing a topic in detail, the developer guide attempts to answer the question -- *"How do I apply this concept in
+the context of my work in Data Systems?"*
 
 Contents
 --------