Merge pull request #5 from Openscapes/website-structure

Add about, policies, admin sections

.gitignore

@@ -1,3 +1,4 @@
 /.quarto/
 /_site/
 *.psd
+.Rproj.user

_quarto.yml

@@ -13,13 +13,20 @@ website:
     left: "© CC-By Openscapes, 2024"
   navbar:
     left:
-      - href: index.qmd
-        text: Home
       - about.qmd
+      - text: Policies
+        menu:
+          - access-policies.qmd
+          - data-storage.qmd
+      - text: "Access Instructions"
+        menu:
+          - github-access.qmd
+          - password-access.qmd
+      - fledging.qmd
 
 format:
   html:
     theme:
       light: [cosmo, custom.scss]
     css: styles.css
-
+    toc: true

about.qmd

@@ -1,5 +1,112 @@
 ---
 title: "About"
+editor: 
+  markdown: 
+    wrap: 72
 ---
 
-About this site
+## JupyterHubs
+
+A key objective of Openscapes JupyterHubs is to minimize “the time to
+science” for researchers, and cloud infrastructure can facilitate
+shortening this time. We use 2i2c-managed JupyterHubs hosted on Amazon
+Web Services (AWS). The purpose of the JupyterHubs is to provide
+initial, exploratory experiences with cloud computing, and to provide a
+platform for running workshops. It is not meant to be a long-term
+solution to support on-going science work or software development. For
+those users that decide working in the cloud is advantageous and want to
+move some of their work there, we are also working on what that can look
+like (fledging).
+
+**Hub Management:** [2i2c](http://2i2c.org/) is a nonprofit that
+designs, develops, and operates JupyterHubs ("Hubs") in the cloud for
+research and education, including Openscapes. 2i2c ensures that Hubs are
+cloud-vendor agnostic and are built using open-source software such as
+JupyterHub and Kubernetes.
+
+**User Management and Access:** Users are given access to a Hub based on
+their reason for accessing the Hub, and the length of time they will
+need access. Short-term access for shorter workshops is differentiated
+from longer-term access for cloud experimentation, Openscapes Champions
+Cohorts, and longer workshops. See our [Access
+Policies](access-policies.qmd) for details.
+
+**Hub Location and Right to Replicate:** Our JupyterHubs are hosted on
+AWS and are in-region with NASA Earthdata (AWS US-West-2). 2i2c gives
+users the [right to replicate](https://2i2c.org/right-to-replicate/)
+their infrastructure. This means that our Hubs could be replicated on
+GoogleEarthEngine or Microsoft Azure, or ported to another AWS region.
+
+With this setup, we have flexibility to support a diverse range of user
+needs. The NASA Openscapes Hub has been used by the NASA Openscapes
+Mentors and other NASA data center (DAAC) staff internally as a testing
+ground for developing cloud tutorials and workflows, but also externally
+in the research community for workshops like those for science teams and
+“Hackathons”, a term used here to describe multi-day events with split
+time for teaching and helping researchers implement concepts into their
+research projects.
+
+*This section drew from the ‘Solution’ section of the White Paper
+entitled, “[The Value of Hosted JupyterHubs in enabling Open NASA Earth
+Science in the Cloud](https://zenodo.org/records/7667299#.Y_Zxt3bMJPY)”
+(Nickles, et.al, 2022).*
+
+## Computing environment
+
+The computing environment in the JuptyerHubs is provided by [Docker
+container images](https://www.docker.com/resources/what-container/),
+enabling a reproducible software environment for all users on the hub
+--- the only software requirements to use the Hub are access to a
+computer and the internet. The images contain the development
+environment (JupyterLab, RStudio, VSCode etc), as well as the software
+stack and required dependencies for R and Python based workflows, and
+optionally other software such as MATLAB and QGIS. Each Hub has a set of
+images users can choose from when they log in, or users can provide
+their own image.
+
+### Core Images
+
+#### NASA-Openscapes
+
+-   [corn](https://github.com/NASA-Openscapes/corn): The base image for
+    Python-based workflows using NASA Earthdata.
+-   [py-rocket](https://github.com/NASA-Openscapes/py-rocket): The base
+    image for R-based workflows using NASA Earthdata.
+
+#### NMFS-Openscapes
+
+-   TBD...
+
+## Openscapes
+
+The Openscapes Team oversees the management of the Hub and Cloud costs.
+
+[Openscapes](https://openscapes.org/) is an open source approach and
+movement that helps researchers and
+those supporting research find each other and feel empowered to conduct
+data-intensive science. Through a creative approach drawing inspiration
+and skills from many places, we provide structures for technical
+skill-building, collaborative teamwork, and inclusive community
+development. Our work builds from many others in the open movement.
+
+Learn more about Openscapes
+[initiatives](https://openscapes.org/initiatives) through our many other
+[open resources](https://openscapes.org/resources),
+[media](https://openscapes.org/media), and
+[events](https://openscapes.org/events), and
+[connect](https://openscapes.org/connect) with us.
+
+## Primary contacts
+
+#### Openscapes
+
+-   Julia Lowndes
+-   Andy Teucher
+
+#### NASA
+
+-   Luis Lopez
+
+#### NMFS
+
+-   Eli Holmes

access-policies.qmd

@@ -0,0 +1,107 @@
+---
+title: "Access Policies"
+---
+
+JupyterHub access has two general categories of use, with different
+means of access depending on the specifics of each use case:
+
+1. **Exploring and experimenting with cloud computing** - this includes Openscapes 
+Champions, and Openscapes Mentors and instructors building expertise in the
+environment. The users are given access to the Hub by membership in a
+[GitHub Team](#access-via-a-github-team) in the relevant GitHub organization.
+2. **Workshop participants** - Participants in workshops hosted by Mentors,
+Openscapes, or collaborators. The type of workshop will dictate the mode of
+access, depending on requirements determined by workshop leads:
+  a. Workshops where learners require access after the workshop (up to three months), 
+     and/or GitHub workflows are part of the curriculum. These workshops should use
+     [GitHub Team-based access](#access-via-a-github-team).
+  b. Workshops where learners do not require access to the hub after the workshop, 
+     and GitHub is not being taught as part of the lessons. These workshops should
+     use [shared password](#access-via-a-shared-password) access.
+
+## Obtaining Access to an Openscapes Hub
+
+### Access via a GitHub Team
+
+Access is controlled by the Openscapes Team, who oversee the management of the 
+Hub and Cloud costs.
+
+There is a GitHub organization for each Hub, and within each organization our 
+JupyterHub users are managed in two (or more) GitHub Teams: 
+
+* **Long-term access**: This access is for Openscapes mentors and team, staff and 
+  others who request a longer-term engagement.
+* **Openscapes Champions**: This access is for teams that participate in the NASA or 
+  NOAA Openscapes Champions Program. 
+These teams have access for up to a year as they experiment with migrating their 
+  workflows to the Cloud. 
+* **Workshops that teach GitHub workflows**: We create additional GitHub teams to manage participants' access. These teams have access for 3 months as they experiment with migrating their workflows to the Cloud. 
+
+**[Instructions for admins on how to add people to the hub using GitHub](github-access.qmd)**
+
+### Access via a shared password
+
+Access is provided on the day of the workshop with a common, global password. The password 
+will be provided to participants at the start of the workshop, and participants will log in with their email address and the shared password. This access method allows us to 
+ensure all workshop participants have easy access for the workshop, without having 
+prior familiarity with GitHub. In general, access to the Hub with a 
+workshop shared password will persist for seven days post-workshop.
+
+**[Instructions for admins on how to set up a shared-password workshop](password-access.qmd)**
+
+## Allowable Uses of 2i2c Hub 
+
+Users who access the Openscapes Hubs agree to use the Hub only for work on activities related to the collaboration with Openscapes. Generally, recommended instance size is the smallest instance (1.9GB RAM and up to 3.75 CPUs). 
+
+Running large or parallel jobs over large geographic areas or over long temporal extents should be cleared with the Openscapes Team by submitting an issue to the [2i2cAccessPolicies repository]( https://github.com/NASA-Openscapes/2i2cAccessPolicies).
+
+<!-- TODO: add/fix repo for access policies for NOAA -->
+
+## Removal From the Openscapes Hub
+
+The Openscapes Hubs are a shared, limited resource that incur real costs. Users are granted access under the terms above and are removed at the end of those limits. Users that haven’t accessed the Hub in more than six months are also removed for security purposes. 
+
+We will do our best to alert users before they lose access to the Openscapes Hub. However, we reserve the right to remove users at any time for any reason. Users that violate the terms of access or incur large Cloud costs without prior permission from the Openscapes Team will be removed immediately.
+
+## Data storage policies
+
+Policies on data storage and use of the `HOME` directory can be found in the [data policies page](data-storage.qmd).
+
+<!-- 
+TODO: Refine and shift to 'costs' page when monthly reporting is in a better place
+
+## Monitoring cloud usage costs
+
+### AWS Cost Explorer
+
+*This is a work in progress, currently with minimal steps and screenshots that we will augment.*
+
+AWS Cost Explorer lets you examine how much your usage costs. When using Credits, your usage does not immediately show up. Select Charge type as "Usage" from the right menu.
+
+![AWS Cost Explorer. Charge type == "Usage"](images/cost-explorer-usage.png){fig-align="center" width="437"}
+
+### AWS Budgeting Alerts
+
+*This is a work in progress, currently with minimal steps and screenshots that we will augment.*
+
+There are two types of alerts we set up.
+
+#### Budgeting alerts
+
+When adding new Cloud credits to our AWS account, we also create a budget and alerts (received via email) as we spend our credits. These are some beginning notes (credit and thank you to Joe Kennedy!).
+
+Create an annual budget of the total Credits left (you may need to calculate this if credits rolled over at the beginning of the calendar year). In the Budget menu, create a Budget. Then select Customize and Cost budget.
+
+![](images/choose-budget-type.png){fig-align="center" width="394"}
+
+Exclude Credits and Refunds, include Discounts. You can elect to receive emails with a regular cadence: weekly, monthly.
+
+We set these up at 50, 75, 90, 95% of the total budget, and we will receive emails at those percentages. The thinking is that we will need to request more credits starting at 50-75%, and then make sure we have them in hand by 90-95%.
+
+#### Threshold alerts
+
+We can also set up email alerts at certain dollar amounts.
+
+![](images/budget-threshold-alerts.png){fig-align="center" width="426"}
+
+We receive emails when we spend \$100, \$200, \$500 of our Credits, which show up in the system as \$1000 intervals. -->