Update spack-stack collaborators (add GMAO), create release task list issue template and CODEOWNERS file (#1748)

* Update various pieces of documentation with most recent list of stakeholders and spack-stack collaborators (add GMAO); create release task list issue template and CODEOWNERS file
* Add missing codeowners and HPCs to .github/CODEOWNERS and .github/ISSUE_TEMPLATE/release_tasklist.md
* [skip ci] Add NAS to .github/ISSUE_TEMPLATE/release_tasklist.md

Author: climbfuji

.github/CODEOWNERS

@@ -0,0 +1,14 @@
+# EPIC
+@natalie-perlin
+@ratkovasic-noaa
+@rickgrubin-noaa
+# JCSDA
+@ashley314
+@eap
+# NASA
+@mathomp4
+# NOAA
+@alexanderrichert-noaa
+@hanglei-noaa
+# NRL
+@climbfuji

.github/ISSUE_TEMPLATE/release_tasklist.md

@@ -0,0 +1,57 @@
+---
+name: Release task list
+about: Create a task list for a spack-stack release
+title: '[RELEASE] release-x.y.z tasks'
+labels: ''
+assignees:
+# EPIC
+- @natalie-perlin
+- @ratkovasic-noaa
+- @rickgrubin-noaa
+# JCSDA
+- @ashley314
+- @eap
+# NASA
+- @mathomp4
+# NOAA
+- @alexanderrichert-noaa
+- @hanglei-noaa
+# NRL
+- @climbfuji
+
+---
+
+## Release task list
+
+Project board: _insert link here_
+
+- [ ] Create release branches `release/x.y` for spack, spack-packages and spack-stack
+- [ ] Update `doc/source/conf.py` and `.gitmodules` to use `release/x.y` instead of `develop`
+- [ ] Clear project board (no open pull requests other than for specific site configs or documentation)
+- [ ] Prepare Wiki page for release information (https://github.com/jcsda/spack-stack/wiki)
+- [ ] Roll out release x.y.z from release branch `release/x.y` and update documentation (readthedocs), site config, and wiki page each time
+    - [ ] Acorn (NOAA-EMC)
+    - [ ] Atlantis (NRL)
+    - [ ] Blueback (NRL)
+    - [ ] Derecho (EPIC)
+    - [ ] Discover (JCSDA)
+    - [ ] Gaea (EPIC)
+    - [ ] Hercules (EPIC)
+    - [ ] Narwhal (NRL)
+    - [ ] NAS (NASA)
+    - [ ] Nautilus (NRL)
+    - [ ] Orion (EPIC)
+    - [ ] S4 (???)
+    - [ ] Ursa (EPIC)
+    - [ ] JCSDA AWS Parallelcluster (JCSDA)
+    - [ ] JCSDA AWS AMI (JCSDA)
+    - [ ] JCSDA CI containers (JCSDA)
+    - [ ] NAVY PW AWS (NRL)
+    - [ ] NOAA PW AWS (EPIC)
+    - [ ] NOAA PW Azure (EPIC)
+    - [ ] NOAA PW Gcloud (EPIC)
+- [ ] Tag spack and spack-packages
+- [ ] Update `doc/source/conf.py` and `.gitmodules` to use tags instead of release branches
+- [ ] Tag spack-stack
+- [ ] Prepare and publish release notes: https://github.com/JCSDA/spack-stack/releases
+- [ ] Close GitHub project

doc/source/Overview.rst

@@ -3,7 +3,7 @@
 Overview
 *************************
 
-spack-stack is a collaborative effort between the NOAA Environmental Modeling Center (EMC), the UCAR Joint Center for Satellite Data Assimilation (JCSDA), the Earth Prediction Innovation Center (EPIC), and the U.S. Naval Research Laboratory (NRL). spack-stack is designed to support the various applications of the supporting agencies such as the Unified Forecast System (UFS) or the Joint Effort for Data assimilation Integration (JEDI). The stack can be installed on a range of platforms, from Linux and macOS laptops to HPC systems, and comes pre-configured for many systems. Users can install the necessary packages for a particular application and later add the missing packages for another application without having to rebuild the entire stack.
+spack-stack is a collaborative effort between the NOAA Environmental Modeling Center (EMC), the UCAR Joint Center for Satellite Data Assimilation (JCSDA), the Earth Prediction Innovation Center (EPIC), the U.S. Naval Research Laboratory (NRL), and the NASA Global Modeling and Assimilation Office (GMAO). spack-stack is designed to support the various applications of the supporting agencies such as the Unified Forecast System (UFS) or the Joint Effort for Data assimilation Integration (JEDI). The stack can be installed on a range of platforms, from Linux and macOS laptops to HPC systems, and comes pre-configured for many systems. Users can install the necessary packages for a particular application and later add the missing packages for another application without having to rebuild the entire stack.
 
  `Spack <https://github.com/spack/spack>`_ is a community-supported, multi-platform, Python-based package manager originally developed by the Lawrence Livermore National Laboratory (LLNL; https://computing.llnl.gov/projects/spack-hpc-package-manager). It is provided as a submodule so that a stable version can be referenced. See the `Spack Documentation <https://spack.readthedocs.io/en/latest>`_ for more information.
 
@@ -13,15 +13,7 @@ spack-stack is mainly a collection of Spack configuration files, but provides a
 
 - ``spack stack setup-meta-modules`` creates compiler, MPI and Python meta-modules for a convenient setup of a user environment using modules (``lua`` and ``tcl``)
 
-spack-stack is maintained by:
-
-- Alex Richert (@AlexanderRichert-NOAA), Hang Lei (@Hang-Lei-NOAA), and Ed Hartnett (@edwardhartnett), NOAA-EMC
-
-- Steve Herbener (@srherbener) and TBD, JCSDA
-
-- Cameron Book (@ulmononian), Natalie Perlin (@natalie-perlin), and Ratko Vasic (@ratkovasic-noaa), EPIC
-
-- Dom Heinzeller (@climbfuji) and Sarah King (@sking112), NRL
+spack-stack is maintained by representatives of the contributing organizations (see `project_charter.md` in this repository for the current list of representatives).
 
 ===============
 Getting started

doc/source/conf.py

@@ -21,7 +21,7 @@
 
 project = 'spack-stack'
 copyright = '2025 '
-author = 'Dominikus Heinzeller, Alexander Richert, Evan Parker, Steve Herbener, Steve Grace, Cameron Book, Ratko Vasic, Natalie Perlin, Rick Grubin'
+author = 'spack-stack collaboration'
 
 # The short X.Y version
 version = 'dev'

project_charter.md

@@ -24,6 +24,7 @@ in installing the large number of packages managed by spack-stack.
 - The UCAR Joint Center for Satellite Data Assimilation (JCSDA)
 - The Earth Prediction Innovation Center (EPIC)
 - The U.S. Naval Research Laboratory (NRL)
+- The NASA Global Modeling and Assimilation Office, (GMAO)
 
 Each stakeholder will designate a small number of developers to assist
 in spack-stack development by becoming a code manager of the
@@ -34,9 +35,10 @@ spack-stack repo.
 Organization | Code Manager(s)
 -------------|----------------
 NOAA EMC | Alex Richert, Hang Lei
-JCSDA | Steve Grace, Evan Parker
+JCSDA | Ashley Griffin, Evan Parker
 EPIC | Rick Grubin, Ratko Vasic
-NRL | Dom Heinzeller, Sarah King
+NRL | Dom Heinzeller, TBD
+NASA | Matthew Thompson, TBD
 
 ## Project Process
 
@@ -81,11 +83,11 @@ install on their systems (see https://spack-stack.readthedocs.io/en/latest/PreCo
 Any stakeholder can perform a release at any time.
 
 The release process:
-* Create a GitHub issue explaining the reason for the release, and to notify all other stakeholders.
+* Create a GitHub issue using the release task list template
 * Unless it is a patch release (increasing the z in x.y.z,), create a project board for the release at https://github.com/JCSDA/spack-stack/projects.
 * Designate any issues that must be fixed before release by assigning it to the epic and the project board, and ensure their completion.
 * Install the release tags (or the final version of the release branches to allow for last-minute site config updates) on all supported platforms.
-* Update the documentation and create release tags for the spack-stack repo and the spack submodule.
+* Update the documentation and create release tags for the spack-stack repo and the spack and spack-packages submodules.
 * Update the GitHub Release Notes.
 * Perform the release on GitHub.
 
@@ -158,14 +160,17 @@ _Sole exception_
 `esmf@8.4.2 + mapl@2.35.2` works with `esmf@8.5.0 + mapl@2.35.2` because auto-generated module name for mapl is `mapl/2.35.2-esmf-8.5.0`
 
 #### Also to consider
+
 Our spack environments are large and complex. Adding more and more packages to the same environment between releases increases the risk of spack concretization errors (rebuilding existing libraries against new dependencies, unintended updates to existing libraries, duplicate packages, …)
 
 Spack-stack unified environments serve multiple applications at the same time: `ufs-weather-model`, `ufs-srw-app`, `skylab` (`jedi-fv3`, `soca`, `ewok`), `jedi-mpas`, `jedi-neptune`, `jedi-um`, `jedi-ufs`, etc. - for each of these, developers may potentially request several package installations “between releases”.
 
 ### Handling library updates for applications
+
 We need to consider two types of installations: test installations and official updates
 
 #### Test installations
+
 Test installations can be requested as part of issues (which should be mandatory for pull requests anyway). These can be more frequent than official updates.
 Issues can be in the application (e.g. `ufs-weather-model` repo) or in spack-stack, clearly describing the need and with a reasonable timeline.
 
@@ -180,6 +185,7 @@ module load fms/2023.02
 The advantage is that it is obvious to the developer, the reviewers and the code managers that a library update in a PR is not officially rolled out everywhere yet. Further, there is no risk to corrupt official spack-stack installations with frequent test installs. 
 
 #### Official updates / patch releases
+
 Official updates should be limited in frequency and are only allowed after full acceptance testing (see test installations above).
 
 Updates that will generate module duplicates require a completely new spack-stack installation. Making these kinds of updates between releases should be the absolute exception when it is really urgent (critical bugs or security issues). We roll out a new spack-stack release every three months anyway!
@@ -189,6 +195,7 @@ Official updates need to be made consistently across all platforms. There shall
 Since official updates require coordination across all platforms, the timeline for these installs must be more generous than for test installs.
 
 ## Lifetime of spack-stack installations
+
 Regular, full releases of spack-stack are made every three months around the end of February, May, August, and November.
 
 spack-stack developers are committed to maintaining a rolling stock of the last four releases, i.e. one year's worth of spack-stack releases. Under special circumstances (e.g. operational implementations that require long-term support, long-running official retrospectives), selected releases may be kept longer. Maintenance in this context refers to addressing bugs or recompiling in the event of an intrusive update to the system. Adding new functionality or new packages is in general limited to the current and future releases. Modifications to past releases that do not impact existing installations, such as the addition of chained environments/custom Spack repositories, or new templates or site configurations, may be considered on a case-by-case basis."