scientific-python · jarrodmillman · Sep 11, 2024 · Mar 6, 2024 · Apr 2, 2024 · Apr 2, 2024
diff --git a/purpose-and-process/_index.md b/purpose-and-process/_index.md
@@ -163,6 +163,80 @@ Projects that adopt a SPEC early should engage in the collaborative
 process leading to the SPEC being endorsed by the Core Projects, to
 ensure that their use cases are incorporated.
 
+#### Badges
+
+Projects can highlight their adoption of specific SPECs with a SPEC badge.
+For example, for SPEC 0, we recommend using
+
+{{< tabs >}}
+
+[[tab]]
+name = 'Rendered badge'
+content = '''
+[![SPEC 0 — Minimum Supported Dependencies](https://img.shields.io/badge/SPEC-0-green?labelColor=%23004811&color=%235CA038)](https://scientific-python.org/specs/spec-0000/)
+'''
+
+[[tab]]
+name = 'Markdown'
+content = '''
+
+```
+[![SPEC 0 — Minimum Supported Dependencies](https://img.shields.io/badge/SPEC-0-green?labelColor=%23004811&color=%235CA038)](https://scientific-python.org/specs/spec-0000/)
+```
+
+'''
+
+[[tab]]
+name = 'reStructuredText'
+content = '''
+
+```
+|SPEC 0 — Minimum Supported Dependencies|
+
+.. |SPEC 0 — Minimum Supported Dependencies| image:: https://img.shields.io/badge/SPEC-0-green?labelColor=%23004811&color=%235CA038
+ :target: https://scientific-python.org/specs/spec-0000/
+```
+
+'''
+
+{{< /tabs >}}
+
+Alternatively, you can use one badge to indicate adoption of multiple SPECs.
+For example, to indicate adoption of SPECs 0, 1, and 4, we recommend the following
+
+{{< tabs >}}
+
+[[tab]]
+name = 'Rendered badge'
+content = '''
+[![Scientific Python Ecosystem Coordination](https://img.shields.io/badge/SPEC-0,1,4-green?labelColor=%23004811&color=%235CA038)](https://scientific-python.org/specs/)
+'''
+
+[[tab]]
+name = 'Markdown'
+content = '''
+
+```
+[![Scientific Python Ecosystem Coordination](https://img.shields.io/badge/SPEC-0,1,4-green?labelColor=%23004811&color=%235CA038)](https://scientific-python.org/specs/)
+```
+
+'''
+
+[[tab]]
+name = 'reStructuredText'
+content = '''
+
+```
+|Scientific Python Ecosystem Coordination|
+
+.. |Scientific Python Ecosystem Coordination| image:: https://img.shields.io/badge/SPEC-0,1,4-green?labelColor=%23004811&color=%235CA038
+ :target: https://scientific-python.org/specs/
+```
+
+'''
+
+{{< /tabs >}}
+
 ### New SPEC Proposals
 
 A good SPEC proposal focuses on a single key recommendation or idea

diff --git a/quickstart.py b/quickstart.py
@@ -50,6 +50,14 @@
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+
+{{{{< spec_badge number="{number}" title="{title}" >}}}}
+
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 <!--

diff --git a/spec-0000/index.md b/spec-0000/index.md
@@ -59,6 +59,12 @@ A core project endorsing this SPEC does **not** imply that that project will pro
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="0" title="Minimum Supported Dependencies" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 ### Motivation

diff --git a/spec-0001/index.md b/spec-0001/index.md
@@ -6,6 +6,7 @@ author:
  - "Stéfan van der Walt <stefanv@berkeley.edu>"
  - "Jon Crall <jon.crall@kitware.com>"
  - "Dan Schult <dschult@colgate.edu>"
+ - "Jarrod Millman <millman@berkeley.edu>"
 discussion: https://discuss.scientific-python.org/t/spec-1-lazy-loading-for-submodules/25
 endorsed-by:
  - ipython
@@ -66,9 +67,11 @@ subpackages lazily.
 A prototype implementation of `lazy_loader` was adapted for
 [napari](https://github.com/napari/napari/pull/2816).
 
-<!--
-Discuss what it means for a project to adopt this SPEC.
--->
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="1" title="Lazy Loading of Submodules and Functions" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
 
 ## Implementation
 

diff --git a/spec-0002/index.md b/spec-0002/index.md
@@ -32,6 +32,12 @@ Briefly discuss what it means for a core project to endorse this SPEC.
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="2" title="API Dispatch" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 <!--

diff --git a/spec-0003/index.md b/spec-0003/index.md
@@ -32,6 +32,12 @@ Briefly discuss what it means for a core project to endorse this SPEC.
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="3" title="Accessibility" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 ### 1. Alt text

diff --git a/spec-0004/index.md b/spec-0004/index.md
@@ -52,6 +52,12 @@ Discuss what it means for a core project to endorse this SPEC.
 Discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="4" title="Using and Creating Nightly Wheels" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 This section outlines how to implement using and building nightly wheels. We assume your

diff --git a/spec-0005/index.md b/spec-0005/index.md
@@ -31,6 +31,12 @@ Briefly discuss what it means for a core project to endorse this SPEC.
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="5" title="CI Best Practices" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 <!--

diff --git a/spec-0006/index.md b/spec-0006/index.md
@@ -68,6 +68,24 @@ This document deals with the situation in which that is not possible, and secret
 
 [^future-access]: Revoking access to a service implies both (a) revoking access to secrets and (b) re-generating those secrets, since the actor could have copied them.
 
+### Core Project Endorsement
+
+<!--
+Discuss what it means for a core project to endorse this SPEC.
+-->
+
+### Ecosystem Adoption
+
+<!--
+Discuss what it means for a project to adopt this SPEC.
+-->
+
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="6" title="Keys to the Castle" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 ### Password storage: hosted
@@ -107,18 +125,6 @@ If a developer's access is removed, the vault is re-encrypted so that that devel
  This ensures that they are of sufficient length and complexity.
 - **SSH keys** must have a password. Ed25519 is the current recommended key type, and can be generated with `ssh-keygen -t ed25519`.
 
-### Core Project Endorsement
-
-<!--
-Discuss what it means for a core project to endorse this SPEC.
--->
-
-### Ecosystem Adoption
-
-<!--
-Discuss what it means for a project to adopt this SPEC.
--->
-
 ## Notes
 
 See [gopass's security goals](https://github.com/gopasspw/gopass/blob/master/docs/security.md#security-goals).

diff --git a/spec-0007/index.md b/spec-0007/index.md
@@ -56,6 +56,24 @@ NumPy, SciPy, scikit-learn, scikit-image, and NetworkX all implement pseudo-rand
 Common keyword arguments include `random_state` and `seed`.
 In practice, the seed is also often controllable using `numpy.random.seed`.
 
+### Core Project Endorsement
+
+Endorsement of this SPEC means that a project considers the standardization and interpretation of the `rng` keyword, as well as avoiding use of global state and legacy bitstream generators, good ideas that are worth implemented widely.
+
+### Ecosystem Adoption
+
+To adopt this SPEC, a project should:
+
+- deprecate the use of `random_state`/`seed` arguments in favor of an `rng` argument in all functions where users need to control pseudo-random number generation,
+- use `numpy.random.default_rng` to validate the `rng` argument and instantiate a `Generator`, and
+- deprecate the use of `numpy.random.seed` to control the random state.
+
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="7" title="Seeding pseudo-random number generation" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 Legacy behavior in packages such as scikit-learn (`sklearn.utils.check_random_state`) typically handle `None` (use the global seed state), an int (convert to `RandomState`), or `RandomState` object.
@@ -137,16 +155,4 @@ As an example, consider how a SciPy function would transition from a `random_sta
 
 {{< include-code "transition_to_rng.py" "python" >}}
 
-### Core Project Endorsement
-
-Endorsement of this SPEC means that a project considers the standardization and interpretation of the `rng` keyword, as well as avoiding use of global state and legacy bitstream generators, good ideas that are worth implemented widely.
-
-### Ecosystem Adoption
-
-To adopt this SPEC, a project should:
-
-- deprecate the use of `random_state`/`seed` arguments in favor of an `rng` argument in all functions where users need to control pseudo-random number generation,
-- use `numpy.random.default_rng` to validate the `rng` argument and instantiate a `Generator`, and
-- deprecate the use of `numpy.random.seed` to control the random state.
-
 ## Notes
diff --git a/spec-0008/index.md b/spec-0008/index.md
@@ -8,6 +8,7 @@ author:
  - "Juanita Gomez <juanitagomezr2112@gmail.com>"
  - "Seth Larson <sethmichaellarson@gmail.com>"
  - "Lars Grüter <lagru@mailbox.org>"
+ - "Jarrod Millman <millman@berkeley.edu>"
 discussion: https://discuss.scientific-python.org/t/spec-8-supply-chain-security
 endorsed-by:
 ---
@@ -29,6 +30,12 @@ Securely _building_ release artifacts will be covered in a later SPEC. This set
 
 While this SPEC is written with GitHub in mind, the same recommendations apply to other services, such as GitLab.
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="8" title="Securing the Release Process" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 With a focus on securing the release artifact distribution process, the following processes and standards should be adopted.

diff --git a/spec-0009/index.md b/spec-0009/index.md
@@ -7,6 +7,7 @@ author:
  - "Inessa Pawson <inessapawson@gmail.com>"
  - "Daniel McCloy <dan@mccloy.info>"
  - "Matt Haberland <mhaberla@calpoly.edu>"
+ - "Jarrod Millman <millman@berkeley.edu>"
 discussion: https://discuss.scientific-python.org/t/spec-9-governance/1229
 is-draft: true
 endorsed-by:
@@ -54,6 +55,12 @@ Briefly discuss what it means for a core project to endorse this SPEC.
 Briefly discuss what it means for a project to adopt this SPEC.
 -->
 
+#### Badges
+
+Projects can highlight their adoption of this SPEC by including a SPEC badge.
+{{< spec_badge number="9" title="Governance" >}}
+To indicate adoption of multiple SPECS with one badge, see [this](../purpose-and-process/#badges).
+
 ## Implementation
 
 ### Choosing a governance model