CI: repository configuration

Author: dmgav

.github/CONTRIBUTING.md

@@ -1,77 +1,74 @@
-See the [Scientific Python Developer Guide][spc-dev-intro] for a detailed
-description of best practices for developing scientific packages.
+# Contributing
 
-[spc-dev-intro]: https://learn.scientific-python.org/development/
+## Getting Started
 
-# Quick development
+* Make sure you have a [GitHub account](https://github.com/signup/free)
+* Submit a ticket for your issue, assuming one does not already exist.
+  * Clearly describe the issue including steps to reproduce when it is a bug.
+  * Make sure you fill in the earliest version that you know has the issue.
+* Fork the repository on GitHub
 
-The fastest way to start with development is to use nox. If you don't have nox,
-you can use `uvx nox` to run it without installing, or `uv tool install nox`. If
-you don't have uv, you can
-[install it a variety of ways](https://docs.astral.sh/uv/getting-started/installation/),
-including with pip, pipx, brew, and just downloading the binary (single file).
 
-To use, run `nox`. This will lint and test using every installed version of
-Python on your system, skipping ones that are not installed. You can also run
-specific jobs:
+## Making Changes
 
-```console
-$ nox -s lint  # Lint only
-$ nox -s tests  # Python tests
-$ nox -s docs  # Build and serve the docs
-$ nox -s build  # Make an SDist and wheel
-```
-
-Nox handles everything for you, including setting up an temporary virtual
-environment for each run.
+* Create a topic branch from where you want to base your work.
+  * This is usually the master branch.
+  * Only target release branches if you are certain your fix must be on that
+    branch.
+  * To quickly create a topic branch based on master; `git checkout -b
+    fix/master/my_contribution master`. Please avoid working directly on the
+    `master` branch.
+* Make commits of logical units.
+* Check for unnecessary whitespace with `git diff --check` before committing.
+* Make sure your commit messages are in the proper format (see below)
+* Make sure you have added the necessary tests for your changes.
+* Run _all_ the tests to assure nothing else was accidentally broken.
 
-# Setting up a development environment manually
+### Writing the commit message
 
-You can set up a development environment by running:
+Commit messages should be clear and follow a few basic rules. Example:
 
-```bash
-uv sync
 ```
+ENH: add functionality X to bluesky.<submodule>.
 
-# Pre-commit
-
-You should prepare pre-commit, which will help you by checking that commits pass
-required checks:
-
-```bash
-uv tool install pre-commit # or brew install pre-commit on macOS
-pre-commit install # Will install a pre-commit hook into the git repo
+The first line of the commit message starts with a capitalized acronym
+(options listed below) indicating what type of commit this is.  Then a blank
+line, then more text if needed.  Lines shouldn't be longer than 72
+characters.  If the commit is related to a ticket, indicate that with
+"See #3456", "See ticket 3456", "Closes #3456" or similar.
 ```
 
-You can also/alternatively run `pre-commit run` (changes only) or
-`pre-commit run --all-files` to check even without installing the hook.
+Describing the motivation for a change, the nature of a bug for bug fixes
+or some details on what an enhancement does are also good to include in a
+commit message. Messages should be understandable without looking at the code
+changes.
 
-# Testing
-
-Use pytest to run the unit checks:
-
-```bash
-uv run pytest
+Standard acronyms to start the commit message with are:
 ```
-
-# Coverage
-
-Use pytest-cov to generate coverage reports:
-
-```bash
-uv run pytest --cov=save-and-restore-api
+API: an (incompatible) API change
+BLD: change related to building numpy
+BUG: bug fix
+CI : continuous integration
+DEP: deprecate something, or remove a deprecated object
+DEV: development tool or utility
+DOC: documentation
+ENH: enhancement
+MNT: maintenance commit (refactoring, typos, etc.)
+REV: revert an earlier commit
+STY: style fix (whitespace, PEP8)
+TST: addition or modification of tests
+REL: related to releases
 ```
+## The Pull Request
 
-# Building docs
-
-You can build and serve the docs using:
+* Now push to your fork
+* Submit a [pull request](https://help.github.com/articles/using-pull-requests) to this branch. This is a start to the conversation.
 
-```bash
-nox -s docs
-```
-
-You can build the docs only with:
+At this point you're waiting on us. We like to at least comment on pull requests within three business days
+(and, typically, one business day). We may suggest some changes or improvements or alternatives.
 
-```bash
-nox -s docs --non-interactive
-```
+Hints to make the integration of your changes easy (and happen faster):
+- Keep your pull requests small
+- Don't forget your unit tests
+- All algorithms need documentation, don't forget the .rst file
+- Don't take changes requests to change your code personally

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,27 @@
+<!--- Provide a general summary of the issue in the Title above -->
+
+## Expected Behavior
+<!--- If you're describing a bug, tell us what should happen -->
+<!--- If you're suggesting a change/improvement, tell us how it should work -->
+
+## Current Behavior
+<!--- If describing a bug, tell us what happens instead of the expected behavior -->
+<!--- If suggesting a change/improvement, explain the difference from current behavior -->
+
+## Possible Solution
+<!--- Not obligatory, but suggest a fix/reason for the bug, -->
+<!--- or ideas how to implement the addition or change -->
+
+## Steps to Reproduce (for bugs)
+<!--- Provide a link to a live example, or an unambiguous set of steps to -->
+<!--- reproduce this bug. Include code to reproduce, if relevant -->
+1.
+2.
+3.
+
+## Context
+<!--- How has this issue affected you? What are you trying to accomplish? -->
+<!--- Providing context helps us come up with a solution that is most useful in the real world -->
+
+## Your Environment
+<!--- Include as many relevant details about the environment you experienced the bug in -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,32 @@
+<!--- Provide a general summary of your changes in the Title above -->
+
+## Description
+<!--- Describe your changes in detail -->
+
+## Motivation and Context
+<!--- Why is this change required? What problem does it solve? -->
+<!--- If it fixes an open issue, please link to the issue here. -->
+
+## Summary of Changes for Release Notes
+<!--- Brief summary of changes that could be copied to the Release Notes. -->
+<!--- Skip this section if this is a maintenance PR (CI, unit tests, typo fix etc.) -->
+<!--- PRs with feature changes will not be merged without this section filled. -->
+
+<!--- Group the changes in the following sections: -->
+
+### Fixed
+
+### Added
+
+### Changed
+
+### Removed
+
+## How Has This Been Tested?
+<!--- Please describe in detail how you tested your changes. -->
+<!--- Include details of your testing environment, and the tests you ran to -->
+<!--- see how your change affects other areas of the code, etc. -->
+
+<!--
+## Screenshots (if appropriate):
+-->

.github/workflows/cd.yml

@@ -0,0 +1,37 @@
+name: pre-commit
+
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  lint:
+    # pull requests are a duplicate of a branch push if within the same repo.
+    if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name != github.repository
+
+    name: Check code style
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+    defaults:
+      run:
+        shell: bash -l {0}
+
+    steps:
+      - name: Checkout the branch
+        uses: actions/checkout@v3
+
+      - name: Set up Python
+        uses: actions/setup-python@v4
+        with:
+          python-version: 3.13
+
+      - name: Install dev dependencies
+        run: |
+          set -vxeuo pipefail
+          pip install .[dev]
+          python -m pip list
+
+      - name: Run pre-commit
+        run: pre-commit run --all-files