Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
85 lines (44 loc) · 5.62 KB

CONTRIBUTING.md

File metadata and controls

85 lines (44 loc) · 5.62 KB

Contributing to xarray-spatial

As stated in the xarray-spatial code of conduct, a primary goal of xarray-spatial is to be inclusive to the largest number of contributors. However, we do have some requests for how contributions should be made. Please read these guidelines before contributing to have a most positive experience with xarray-spatial.

Getting Started

Information about installation and setting up a development environment can be found at the Getting Started page.

Choosing something to work on

The issue tracker has a list of items that you can start working on. In order to avoid duplication of effort, it's always a good idea to comment on an issue and let everybody know that you intend to work on it.

Opening a new issue

  1. Avoid duplicate reports. Search GitHub for similar or identical issues. Keyword searches for your error messages are usually effective.

  2. The issue may already be resolved. Always try to reproduce the issue in the latest stable release.

  3. Always include a minimal, self-contained, reproducible test case or example. It is not possible to investigate issues that cannot be reproduced.

  4. Include relevant system information.

  5. State the expected behavior.

Creating a pull request (PR)

  1. Make sure that there is a corresponding issue for your change first. If there isn't yet, create one.

  2. Create a fork of the xarray-spatial repository on GitHub (this is only done before first) contribution.

  3. Create a branch off the main branch with a meaningful name. Preferably include issue number and a few keywords, so that we will have a rough idea what the branch refers to, without looking up the issue.

  4. Commit your changes and push them to GitHub.

  5. Create a pull request against the default base branch. The PR must have a meaningful title and a message explaining what was achieved, what remains to be done, maybe an example, etc.

  6. Use the Create draft pull request option as you first open a pull request, so everyone knows it's a work in progress. Once you finish the work on the pull request you can convert it to Ready for review. In addition to this, please use the labels WIP and ready to merge.

  7. We don't accept code contributions without tests. If there are valid reasons for not including a test, please discuss this in the issue.

  8. We will review your PR as time permits. Reviewers may comment on your contributions, ask you questions regarding the implementation or request changes. If changes are requested, push new commits to the existing branch. Do NOT rebase, amend, or cherry-pick published commits. Any of those actions will make us start the review from scratch. If you need updates from main, just merge it into your branch.

AI-Assisted Contribution and Review

xarray-spatial welcomes responsible AI-assisted development and review when it helps contributors move faster, improve quality, and reduce maintainer burden. The project has limited dedicated development capacity, so contributors are encouraged to use AI tools for testing, debugging, feature work, documentation, deployment, and release preparation.

Attribution and responsibility belong to human contributors. Do not add AI tools, coding agents, or AI companies as commit authors, co-authors, reviewers, or attribution lines in commits, pull requests, changelogs, or release notes.

Please avoid attribution such as:

Co-authored-by: Claude <...>
Co-authored-by: ChatGPT <...>
Generated with Claude Code
Generated by Copilot
Reviewed-by: <AI tool>

If AI-assisted code introduces a bug, security issue, regression, or incorrect behavior, the responsible party is the human contributor who submitted and reviewed the change. AI tools may assist the work, but they do not own the work.

Review Expectations

Before submitting a pull request, contributors should review and use the relevant commands in:

.claude/commands/

These command markdown files reflect current project expectations for performance, accuracy, security, testing, maintainability, deployment, and release readiness. New contributors should read through them to understand the project's quality standards.

Contributors who do not use Claude Code can adapt the command markdown files into prompts or checklists for their preferred AI tools and review workflows. The important part is the quality review they represent, not the specific tool used to run them.

Where applicable, run the relevant sweep or review commands before requesting maintainer review. If a command flags an issue, either address it or clearly explain why it is acceptable for the current change.

Copilot code review may run on pull requests as automated review assistance. Its feedback is useful, but it does not replace human responsibility or maintainer judgment.

Current Priority

The next sprint is focused on stabilizing xarray-spatial for its first major release. Contributors should prioritize bug fixes, reliability, tests, release blockers, and performance, accuracy, or security issues. New features should avoid adding significant release risk unless they are essential.

The preferred contribution style is fast, careful, and human-accountable: use AI aggressively to improve velocity and quality, but keep ownership and attribution with the people contributing to the project.

Attribution

Portions of text derived from [Bokeh CONTRIBUTING file]: (https://github.com/bokeh/bokeh/blob/branch-3.4/.github/CONTRIBUTING.md)