diff --git a/.github/ISSUE_TEMPLATE/0_bug.yml b/.github/ISSUE_TEMPLATE/0_bug.yml
index a53f6fba..b530bb12 100644
--- a/.github/ISSUE_TEMPLATE/0_bug.yml
+++ b/.github/ISSUE_TEMPLATE/0_bug.yml
@@ -1,3 +1,5 @@
+# edit this in https://github.com/conda/infrastructure
+
name: Bug Report
description: Create a bug report.
labels:
@@ -13,7 +15,7 @@ body:
Since there are already a lot of open issues, please also take a moment to search existing ones to see if your bug has already been reported. If you find something related, please upvote that issue and provide additional details as necessary.
- 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ 💐 Thank you for helping to make `conda/issue-tracker` better. We would be unable to improve `conda/issue-tracker` without our community!
- type: checkboxes
id: checks
attributes:
@@ -31,45 +33,7 @@ body:
description: What should have happened instead? Please provide as many details as possible. The more information provided, the more likely we are able to replicate your problem and offer a solution.
validations:
required: true
- - type: textarea
- id: info
- attributes:
- label: Conda Info
- description: |
- Let's collect some basic information about your conda install.
-
- Please run the following command from your command line and paste the output below.
-
- ```bash
- conda info
- ```
- render: shell
- - type: textarea
- id: config
- attributes:
- label: Conda Config
- description: |
- Let's collect any customizations you may have for your conda install.
-
- Please run the following command from your command line and paste the output below.
-
- ```bash
- conda config --show-sources
- ```
- render: shell
- - type: textarea
- id: list
- attributes:
- label: Conda list
- description: |
- The packages installed into your environment can offer clues as to the problem you are facing.
-
- Please activate the environment within which you are encountering this bug, run the following command from your command line, and paste the output below.
- ```bash
- conda list --show-channel-urls
- ```
- render: shell
- type: textarea
id: context
attributes:
diff --git a/.github/ISSUE_TEMPLATE/1_feature.yml b/.github/ISSUE_TEMPLATE/1_feature.yml
index bc022b41..86ebfb8d 100644
--- a/.github/ISSUE_TEMPLATE/1_feature.yml
+++ b/.github/ISSUE_TEMPLATE/1_feature.yml
@@ -1,3 +1,5 @@
+# edit this in https://github.com/conda/infrastructure
+
name: Feature Request
description: Create a feature request.
labels:
@@ -13,7 +15,7 @@ body:
Since there are already a lot of open issues, please also take a moment to search existing ones to see if your feature request has already been submitted. If you find something related, please upvote that issue and provide additional details as necessary.
- 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ 💐 Thank you for helping to make `conda/issue-tracker` better. We would be unable to improve `conda/issue-tracker` without our community!
- type: checkboxes
id: checks
attributes:
diff --git a/.github/ISSUE_TEMPLATE/2_documentation.yml b/.github/ISSUE_TEMPLATE/2_documentation.yml
index f3ce0408..56e2fb8e 100644
--- a/.github/ISSUE_TEMPLATE/2_documentation.yml
+++ b/.github/ISSUE_TEMPLATE/2_documentation.yml
@@ -1,3 +1,5 @@
+# edit this in https://github.com/conda/infrastructure
+
name: Documentation
description: Create a documentation related issue.
labels:
diff --git a/.github/ISSUE_TEMPLATE/epic.yml b/.github/ISSUE_TEMPLATE/epic.yml
index 9b3637f9..2bf64ea6 100644
--- a/.github/ISSUE_TEMPLATE/epic.yml
+++ b/.github/ISSUE_TEMPLATE/epic.yml
@@ -1,3 +1,5 @@
+# edit this in https://github.com/conda/infrastructure
+
name: Epic
description: A collection of related tickets.
labels:
@@ -15,7 +17,8 @@ body:
Since there are already a lot of open issues, please also take a moment to search existing ones to see if a similar epic has already been opened. If you find something related, please upvote that issue and provide additional details as necessary.
- 💐 Thank you for helping to make Conda better. We would be unable to improve Conda without our community!
+ 💐 Thank you for helping to make `conda/issue-tracker` better. We would be unable to improve `conda/issue-tracker` without our community!
+
- type: checkboxes
id: checks
attributes:
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 760ec06c..29d9bba4 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -8,6 +8,8 @@
- any noteworthy (or hacky) choices to be aware of,
- or what the problem resolved here looked like. -->
+
+
+ - Conda Org COC: https://github.com/conda/issue-tracker/blob/main/CODE_OF_CONDUCT.md
+ - Contributing docs: https://github.com/conda/issue-tracker/blob/main/CONTRIBUTING.md -->
diff --git a/.github/template-files/config.yml b/.github/template-files/config.yml
new file mode 100644
index 00000000..10381688
--- /dev/null
+++ b/.github/template-files/config.yml
@@ -0,0 +1,50 @@
+conda/governance:
+ # [required] community files
+ - CODE_OF_CONDUCT.md
+
+conda/infrastructure:
+ # [required] general workflows
+ - .github/workflows/cla.yml
+ - .github/workflows/update.yml
+
+ # [optional] to include repo in https://github.com/orgs/conda/projects/2
+ - .github/workflows/issues.yml
+ - .github/workflows/labels.yml
+ - .github/workflows/project.yml
+
+ # [optional] stale bot workflows
+ - .github/workflows/stale.yml
+ - .github/workflows/lock.yml
+
+ # [optional] general processes for the conda org
+ - src: templates/HOW_WE_USE_GITHUB.md
+ dst: HOW_WE_USE_GITHUB.md
+
+ # [optional] standard issue templates
+ - src: templates/issues/bug.yml
+ dst: .github/ISSUE_TEMPLATE/0_bug.yml
+
+ - src: templates/issues/feature.yml
+ dst: .github/ISSUE_TEMPLATE/1_feature.yml
+
+ - src: templates/issues/documentation.yml
+ dst: .github/ISSUE_TEMPLATE/2_documentation.yml
+
+ - src: templates/issues/epic.yml
+ dst: .github/ISSUE_TEMPLATE/epic.yml
+
+ # [optional] standard PR template
+ # - src: templates/pull_requests/news_tests_docs.md
+ # dst: .github/template-files/templates/pull_request_template_details.md
+ - src: templates/pull_requests/base.md
+ dst: .github/PULL_REQUEST_TEMPLATE.md
+
+ # [optional] rever release files
+ # - src: templates/releases/RELEASE.md
+ # dst: RELEASE.md
+ # with:
+ # placeholder: YY.M
+ # - src: templates/releases/rever.xsh
+ # dst: rever.xsh
+ # - src: templates/releases/TEMPLATE
+ # dst: news/TEMPLATE
diff --git a/.github/workflows/cla.yml b/.github/workflows/cla.yml
index ad56cf6e..42d24ec3 100644
--- a/.github/workflows/cla.yml
+++ b/.github/workflows/cla.yml
@@ -15,10 +15,10 @@ jobs:
&& github.event.comment.body == '@conda-bot check'
|| github.event_name == 'pull_request_target'
)
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
steps:
- name: Check CLA
- uses: conda/actions/check-cla@1e442e090ad28c9b0f85697105703a303320ffd1
+ uses: conda/actions/check-cla@7f6830b1428a9bd47f0b068892c77eae95207037 # v26.1.0
with:
# [required]
# A token with ability to comment, label, and modify the commit status
diff --git a/.github/workflows/issues.yml b/.github/workflows/issues.yml
index 7a114d6d..573ef0f3 100644
--- a/.github/workflows/issues.yml
+++ b/.github/workflows/issues.yml
@@ -20,15 +20,15 @@ jobs:
!github.event.repository.fork
&& !github.event.issue.pull_request
&& contains(github.event.issue.labels.*.name, 'pending::feedback')
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
steps:
# remove [pending::feedback]
- - uses: actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0
+ - uses: actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0
with:
labels: ${{ env.FEEDBACK_LBL }}
github_token: ${{ secrets.PROJECT_TOKEN }}
# add [pending::support], if still open
- - uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf
+ - uses: actions-ecosystem/action-add-labels@18f1af5e3544586314bbe15c0273249c770b2daf # v1.1.3
if: github.event.issue.state == 'open'
with:
labels: ${{ env.SUPPORT_LBL }}
diff --git a/.github/workflows/labels.yml b/.github/workflows/labels.yml
index e6817ddf..7ba0ec7d 100644
--- a/.github/workflows/labels.yml
+++ b/.github/workflows/labels.yml
@@ -5,38 +5,45 @@ on:
# https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_dispatch
workflow_dispatch:
inputs:
- dryrun:
- description: 'dryrun: Preview changes to labels without editing them (true|false)'
- required: true
+ delete-unmapped:
+ description: Delete labels not mapped in either global or local label configurations.
+ default: false
+ type: boolean
+
+ dry-run:
+ description: Run label synchronization workflow without making any changes.
+ default: false
type: boolean
- default: true
jobs:
sync:
if: '!github.event.repository.fork'
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
env:
GLOBAL: https://raw.githubusercontent.com/conda/infra/main/.github/global.yml
LOCAL: .github/labels.yml
steps:
- - uses: actions/checkout@0ad4b8fadaa221de15dcec353f45205ec38ea70b
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
- id: has_local
- uses: andstor/file-existence-action@076e0072799f4942c8bc574a82233e1e4d13e9d6
+ uses: andstor/file-existence-action@076e0072799f4942c8bc574a82233e1e4d13e9d6 # v3.0.0
with:
files: ${{ env.LOCAL }}
+
- name: Global Only
- uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a
+ uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a # v2.3.3
if: steps.has_local.outputs.files_exists == 'false'
with:
config-file: ${{ env.GLOBAL }}
- delete-other-labels: true
- dry-run: ${{ github.event.inputs.dryrun }}
+ delete-other-labels: ${{ inputs.delete-unmapped }}
+ dry-run: ${{ inputs.dry-run }}
+
- name: Global & Local
- uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a
+ uses: EndBug/label-sync@52074158190acb45f3077f9099fea818aa43f97a # v2.3.3
if: steps.has_local.outputs.files_exists == 'true'
with:
config-file: |
${{ env.GLOBAL }}
${{ env.LOCAL }}
- delete-other-labels: true
- dry-run: ${{ github.event.inputs.dryrun }}
+ delete-other-labels: ${{ inputs.delete-unmapped }}
+ dry-run: ${{ inputs.dry-run }}
diff --git a/.github/workflows/lock.yml b/.github/workflows/lock.yml
index 2204b62d..7e73297b 100644
--- a/.github/workflows/lock.yml
+++ b/.github/workflows/lock.yml
@@ -15,12 +15,12 @@ permissions:
jobs:
lock:
if: '!github.event.repository.fork'
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
steps:
- - uses: dessant/lock-threads@1bf7ec25051fe7c00bdd17e6a7cf3d7bfb7dc771
+ - uses: dessant/lock-threads@7266a7ce5c1df01b1c6db85bf8cd86c737dadbe7 # v6.0.0
with:
# Number of days of inactivity before a closed issue is locked
- issue-inactive-days: 365
+ issue-inactive-days: 180
# Do not lock issues created before a given timestamp, value must follow ISO 8601
exclude-issue-created-before: ''
# Do not lock issues with these labels, value must be a comma separated list of labels or ''
@@ -29,7 +29,6 @@ jobs:
add-issue-labels: locked
# Reason for locking an issue, value must be one of resolved, off-topic, too heated, spam or ''
issue-lock-reason: resolved
-
# Number of days of inactivity before a closed pull request is locked
pr-inactive-days: 365
# Do not lock pull requests created before a given timestamp, value must follow ISO 8601
diff --git a/.github/workflows/project.yml b/.github/workflows/project.yml
index 7d06584c..9ff94eb8 100644
--- a/.github/workflows/project.yml
+++ b/.github/workflows/project.yml
@@ -1,9 +1,6 @@
name: Add to Project
on:
- issues:
- types:
- - opened
pull_request_target:
types:
- opened
@@ -11,11 +8,10 @@ on:
jobs:
add_to_project:
if: '!github.event.repository.fork'
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
steps:
- - uses: actions/add-to-project@9bfe908f2eaa7ba10340b31e314148fcfe6a2458
+ - uses: actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e # v1.0.2
with:
- # issues are added to the Planning project
# PRs are added to the Review project
- project-url: https://github.com/orgs/conda/projects/${{ github.event_name == 'issues' && 2 || 16 }}
+ project-url: https://github.com/orgs/conda/projects/16
github-token: ${{ secrets.PROJECT_TOKEN }}
diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml
index 78f4ac5e..00e91181 100644
--- a/.github/workflows/stale.yml
+++ b/.github/workflows/stale.yml
@@ -21,7 +21,7 @@ permissions:
jobs:
stale:
if: '!github.event.repository.fork'
- runs-on: ubuntu-latest
+ runs-on: ubuntu-slim
strategy:
matrix:
include:
@@ -33,12 +33,12 @@ jobs:
days-before-issue-stale: 90
days-before-issue-close: 21
steps:
- - uses: conda/actions/read-yaml@1e442e090ad28c9b0f85697105703a303320ffd1
+ - uses: conda/actions/read-yaml@7f6830b1428a9bd47f0b068892c77eae95207037 # v26.1.0
id: read_yaml
with:
path: https://raw.githubusercontent.com/conda/infra/main/.github/messages.yml
- - uses: actions/stale@28ca1036281a5e5922ead5184a1bbf96e5fc984e
+ - uses: actions/stale@b5d41d4e1d5dceea10e7104786b73624c18a190f # v10.2.0
id: stale
with:
# Only issues with these labels are checked whether they are stale
diff --git a/.github/workflows/update.yml b/.github/workflows/update.yml
new file mode 100644
index 00000000..c598ba68
--- /dev/null
+++ b/.github/workflows/update.yml
@@ -0,0 +1,124 @@
+name: Update Repository
+
+on:
+ # every Sunday at 00:36 UTC
+ # https://crontab.guru/#36_2_*_*_0
+ schedule:
+ - cron: 36 2 * * 0
+
+ workflow_dispatch:
+
+ issue_comment:
+ types:
+ - created
+
+jobs:
+ update:
+ if: >-
+ !github.event.repository.fork
+ && (
+ github.event_name == 'schedule'
+ || github.event_name == 'workflow_dispatch'
+ || (
+ github.event_name == 'issue_comment'
+ && github.event.issue.pull_request
+ && (
+ github.event.comment.body == '@conda-bot render'
+ || github.event.comment.body == '@conda-bot recreate'
+ )
+ )
+ )
+ runs-on: ubuntu-slim
+ steps:
+ - if: github.event_name == 'issue_comment'
+ uses: peter-evans/create-or-update-comment@e8674b075228eee787fea43ef493e45ece1004c9 # v5.0.0
+ with:
+ comment-id: ${{ github.event.comment.id }}
+ reactions: eyes
+ reactions-edit-mode: replace
+ token: ${{ secrets.SYNC_TOKEN }}
+
+ - if: github.event.comment.body == '@conda-bot render'
+ name: Configure git origin
+ run: |
+ echo REPOSITORY=$(curl --silent ${{ github.event.issue.pull_request.url }} | jq --raw-output '.head.repo.full_name') >> $GITHUB_ENV
+ echo REF=$(curl --silent ${{ github.event.issue.pull_request.url }} | jq --raw-output '.head.ref') >> $GITHUB_ENV
+
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+ with:
+ repository: ${{ env.REPOSITORY || github.repository }}
+ ref: ${{ env.REF || '' }}
+ token: ${{ secrets.SYNC_TOKEN }}
+
+ - name: Configure git user
+ run: |
+ git config --global user.name 'Conda Bot'
+ git config --global user.email '18747875+conda-bot@users.noreply.github.com'
+
+ - uses: conda/actions/combine-durations@7f6830b1428a9bd47f0b068892c77eae95207037 # v26.1.0
+ id: durations
+ continue-on-error: true
+
+ - uses: conda/actions/template-files@7f6830b1428a9bd47f0b068892c77eae95207037 # v26.1.0
+ id: templates
+ continue-on-error: true
+
+ - name: Commit changes
+ # no-op if there are no updates
+ continue-on-error: true
+ run: |
+ git add .
+ git commit --message "🤖 updated file(s)"
+
+ - if: github.event.comment.body != '@conda-bot render'
+ name: Create fork
+ # no-op if the repository is already forked
+ run: echo FORK=$(gh repo fork --clone=false --default-branch-only 2>&1 | awk '{print $1}') >> $GITHUB_ENV
+ env:
+ GH_TOKEN: ${{ secrets.SYNC_TOKEN }}
+
+ - if: github.event.comment.body != '@conda-bot render'
+ id: create
+ # no-op if no commits were made
+ uses: peter-evans/create-pull-request@c0f553fe549906ede9cf27b5156039d195d2ece0 # v8.1.0
+ with:
+ push-to-fork: ${{ env.FORK }}
+ token: ${{ secrets.SYNC_TOKEN }}
+ branch: update
+ delete-branch: true
+ title: 🤖 Update infrastructure file(s)
+ body: |
+ [update.yml]: ${{ github.server_url }}/${{ github.repository }}/blob/main/.github/workflows/update.yml
+
+ Your friendly repository updater.
+
+ ${{ steps.durations.outputs.summary }}
+
+ ${{ steps.templates.outputs.summary }}
+
+ This PR was triggered by @${{ github.triggering_actor }} via ${{ github.event_name }}.
+
+
+ Commands
+
+ Trigger actions by commenting on this PR:
+
+ - `@conda-bot render` will run rendering workflows and commit and push any changes to this PR
+ - `@conda-bot recreate` will recreate this PR, overwriting any edits that have been made to it
+
+
+
+ ###### Auto-generated by the [`update.yml`][update.yml] workflow, see ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}.
+
+ - if: github.event.comment.body == '@conda-bot render'
+ id: update
+ name: Push changes
+ run: git push --force-with-lease
+
+ - if: always() && github.event_name == 'issue_comment'
+ uses: peter-evans/create-or-update-comment@e8674b075228eee787fea43ef493e45ece1004c9 # v5.0.0
+ with:
+ comment-id: ${{ github.event.comment.id }}
+ reactions: ${{ (steps.create.conclusion == 'success' || steps.update.conclusion == 'success') && 'hooray' || 'confused' }}
+ reactions-edit-mode: replace
+ token: ${{ secrets.SYNC_TOKEN }}
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 53c7ebb7..ce31b940 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -1,6 +1,6 @@
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
- rev: v4.6.0
+ rev: v6.0.0
hooks:
# standard end of line/end of file cleanup
- id: mixed-line-ending
@@ -12,30 +12,30 @@ repos:
- id: check-json
# catch git merge/rebase problems
- id: check-merge-conflict
- - repo: https://github.com/psf/black
- rev: 24.4.0
+ - repo: https://github.com/psf/black-pre-commit-mirror
+ rev: 26.3.1
hooks:
- id: black
types_or: [python]
- repo: https://github.com/asottile/blacken-docs
- rev: 1.16.0
+ rev: 1.20.0
hooks:
- id: blacken-docs
additional_dependencies: [black]
types_or: [python]
- repo: https://github.com/PyCQA/flake8
- rev: 7.0.0
+ rev: 7.3.0
hooks:
- id: flake8
types_or: [python]
- repo: https://github.com/PyCQA/pylint
- rev: v3.1.0
+ rev: v4.0.5
hooks:
- id: pylint
args: [--exit-zero]
types_or: [python]
- repo: https://github.com/PyCQA/bandit
- rev: 1.7.8
+ rev: 1.9.4
hooks:
- id: bandit
args: [--exit-zero]
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 663464fe..d983bc7f 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -1,8 +1,5 @@
# Conda Organization Code of Conduct
-> [!NOTE]
-> Below is the short version of our CoC, see the long version [here](https://github.com/conda-incubator/governance/blob/main/CODE_OF_CONDUCT.md).
-
# The Short Version
Be kind to others. Do not insult or put down others. Behave professionally. Remember that harassment and sexist, racist, or exclusionary jokes are not appropriate for the conda Organization.
@@ -18,3 +15,289 @@ Thank you for helping make this a welcoming, friendly community for all.
* Report a code of conduct incident [using a form](https://form.jotform.com/221527028480048).
* Report a code of conduct incident via email: [conduct@conda.org](mailto:conduct@conda.org).
* Contact [an individual committee member](#committee-membership) or [CoC event representative](#coc-representatives) to report an incident in confidence.
+
+
+
+And now the longer version...
+
+# Conda Organization Diversity Statement
+
+The conda Organization welcomes and encourages participation in our community by people of all backgrounds and identities. We are committed to promoting and sustaining a culture that values mutual respect, tolerance, and learning, and we work together as a community to help each other live out these values.
+
+We have created this diversity statement because we believe that a diverse community is stronger, more vibrant, and produces better software and better science. A diverse community where people treat each other with respect has more potential contributors, more sources for ideas, and fewer shared assumptions that might hinder development or research.
+
+Although we have phrased the formal diversity statement generically to make it all-inclusive, we recognize that there are specific identities that are impacted by systemic discrimination and marginalization. We welcome all people to participate in the conda Organization community regardless of their identity or background.
+
+# Conda Organization Code of Conduct: Introduction & Scope
+
+This code of conduct should be honored by everyone who participates in the conda Organization community. It should be honored in any conda Organization-related activities, by anyone claiming affiliation with the conda Organization, and especially when someone is representing the conda Organization in any role (including as an event volunteer or speaker).
+
+This code of conduct applies to all spaces managed by the conda Organization, including all public and private mailing lists, issue trackers, wikis, forums, and any other communication channel used by our community. The code of conduct equally applies at conda Organization events and governs standards of behavior for attendees, speakers, volunteers, booth staff, and event sponsors.
+
+This code is not exhaustive or complete. It serves to distill our understanding of a collaborative, inclusive community culture. Please try to follow this code in spirit as much as in letter, to create a friendly and productive environment that enriches the conda Organization community.
+
+The conda Organization Code of Conduct follows below.
+
+# Standards for Behavior
+
+The conda Organization is a worldwide community. All communication should be appropriate for a professional audience including people of many different backgrounds.
+
+**Please always be kind and courteous. There's never a need to be mean or rude or disrespectful.** Thank you for helping make this a welcoming, friendly community for all.
+
+We strive to:
+
+**Be empathetic, welcoming, friendly, and patient.** We remember that the conda Organization is crafted by human beings who deserve to be treated with kindness and empathy. We work together to resolve conflict and assume good intentions. We may all experience some frustration from time to time, but we do not allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one.
+
+**Be collaborative.** Our work depends on the participation of many people, and in turn others depend on our work. Open source communities depend on effective and friendly collaboration to achieve their goals.
+
+**Be inquisitive.** Nobody knows everything! Asking questions early avoids many problems later, so we encourage questions, although we may direct them to the appropriate forum. We will try hard to be responsive and helpful.
+
+**Be careful in the words that we choose.** We are careful and respectful in our communication and we take responsibility for our own speech. Be kind to others. Do not insult or put down other members of the community.
+
+## Unacceptable Behavior
+
+We are committed to making participation in this community a harassment-free experience.
+
+We will not accept harassment or other exclusionary behaviors, such as:
+
+- The use of sexualized language or imagery
+- Excessive profanity (please avoid curse words; people differ greatly in their sensitivity to swearing)
+- Posting sexually explicit or violent material
+- Violent or intimidating threats or language directed against another person
+- Inappropriate physical contact and/or unwelcome sexual attention or sexual comments
+- Sexist, racist, or otherwise discriminatory jokes and language
+- Trolling or insulting and derogatory comments
+- Written or verbal comments which have the effect of excluding people on the basis of membership in a specific group, including level of experience, gender, gender identity and expression, sexual orientation, disability, neurotype, personal appearance, body size, race, ethnicity, age, religion, or nationality
+- Public or private harassment
+- Sharing private content, such as emails sent privately or non-publicly, or direct message history, without the sender's consent
+- Continuing to initiate interaction (such as photography, recording, messaging, or conversation) with someone after being asked to stop
+- Sustained disruption of talks, events, or communications, such as heckling of a speaker
+- Publishing (or threatening to post) other people's personally identifying information ("doxing"), such as physical or electronic addresses, without explicit permission
+- Other unethical or unprofessional conduct
+- Advocating for, or encouraging, any of the above behaviors
+
+The conda Organization prioritizes marginalized people’s safety over privileged people’s comfort. The conda CoC Committee reserves the right not to act on complaints including, but not limited to:
+
+* ‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’.
+* Reasonable communication of boundaries, such as “leave me alone,” “go away,” or “I’m not discussing this with you.”
+* Communicating in a ‘tone’ you don’t find congenial.
+* Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptions.
+
+## Behavior Outside of conda Organization Spaces
+
+The CoC Committee does not influence behavior and membership in spaces outside the conda Organization. However, if you are being harassed by a member of the conda community outside our spaces, you may still report it to the CoC Committee. We will take all good-faith reports of harassment by conda community members seriously. This includes harassment outside our spaces and harassment that took place at any point in time.
+
+The CoC Committee reserves the right to exclude people from conda Organization spaces based on their past behavior, including behavior outside conda Organization spaces and behavior towards people who are not in the conda community.
+
+# Confidentiality and Public Statements to the Community
+
+The CoC Committee will keep the identity of the reporter confidential.
+
+Whenever possible, CoC cases will be reported to the community. The level of detail in reports will vary from case to case. Reports will describe at least the type of infraction that was reported, and the Committee's decision and any action taken. In most cases, the report will not include personally identifiable information.
+
+# Live Events
+
+> **If you feel your safety is in jeopardy or the situation is an emergency, we urge you to contact local law enforcement before making a report to the event's Code of Conduct committee members, [representatives](#coc-representatives), or other staff.** (In the U.S., call 911.)
+
+Live events present particular challenges:
+
+**Code of conduct reports, and consequences that stem from them, merit a thoughtful and deliberative process. Decisions and consequences matter for the reporter, the reported, and for the community at large. However, many reports, especially at live events, require rapid action to quickly address the behavior being reported.**
+
+To better support situations where immediate action may be required, these guidelines are used *during* live events:
+
+* All conda Organization events will have specific, named Code of Conduct contacts for the events.
+* The names and contact mechanisms for the Code of Conduct representatives will be clearly and frequently communicated to event participants.
+
+## CoC Representatives
+
+Every conda Organization associated event will have named CoC Committee members or *CoC representatives* that are the first point of contact for that event. Who these people are will be clearly and frequently communicated to event participants. CoC approved representatives are used when there are no committee members participating in the event.
+
+## Live Events: Reporting and Actions
+At conda Organization events, Code of Conduct committee members or representatives will attempt to gather and write down [information](#what-to-include-in-a-report) from anyone making a verbal report at a live event. Recording the details in writing is exceedingly important in order for us to effectively respond to reports. If event staff write down a report taken verbally, then the person making the report will be asked to review the written report for accuracy.
+
+For reports made during live events, or in any situation where urgent action is needed:
+
+* Any two (or more) event organizers, event staff, CoC Committee members or CoC representatives can decide if immediate action is to be taken and what that action is. In exceptionally dangerous situations, this decision can be made by a single person.
+* These rapid decisions can be reconsidered during the event as more information becomes available.
+* The scope of any rapid decision is limited to the current event / situation.
+* The report, any related information, and any decisions and consequences will be reported to the full Code of Conduct Committee as soon as possible.
+
+The full Code of Conduct Committee will then consider the report using the full timeline and processes defined below. The Committee may decide to apply consequences in other spaces beyond the space where the behavior was reported.
+
+Potential *immediate* consequences for violating the conda Organization Code of Conduct at a live event include, but are not limited to:
+
+- Warning the person to cease their behavior and that any further reports will result in sanctions
+- Requiring that the person avoid any interaction with, and physical proximity to, the person they are harassing for the remainder of the event
+- Ending a talk that violates the policy early
+- Not publishing the video or slides of a talk that violated the policy
+- Not allowing a speaker who violated the policy to give (further) talks at the event now or in the future
+- Immediately ending any event volunteer responsibilities and privileges the reported person holds
+- Expelling the person from the event without a refund
+- Requiring that the person immediately leave the event and not return
+- Any other response that the CoC members, representatives, or event staff deem necessary and appropriate to the situation
+
+# Reporting Guidelines
+
+If you believe someone is violating the code of conduct, please report this in a timely manner. Code of conduct violations reduce the value of the community for everyone. The conda Code of Conduct (CoC) Committee and the conda Organization take reports of misconduct very seriously and are committed to preserving and maintaining the welcoming nature of our community.
+
+> [!NOTE]
+> You are also encouraged to reach out to the conda Code of Conduct (CoC) Committee if you want clarification on something, if you notice some borderline behavior, or just have a concern. Send us a note at [conduct@conda.org](mailto:conduct@conda.org).
+
+All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The conda CoC Committee commits to maintaining confidentiality with regard to the reporter of an incident.
+
+For possibly unintentional breaches of the code of conduct, you may want to respond to the person and point out this code of conduct (either in public or in private, whatever is most appropriate). If you would prefer not to do that, please report the issue to the conda CoC Committee directly.
+
+Take care of each other. Alert someone if you notice a dangerous situation, someone in distress, or violations of this code of conduct, even if they seem inconsequential.
+
+## How to Submit a Report
+
+The CoC Committee is committed to promptly addressing any reported issues. If you have experienced or witnessed behavior that violates the conda Organization Code of Conduct, please let us know.
+
+You can report an incident
+
+* via the **[Incident Reporting Form](https://form.jotform.com/221527028480048)**
+* via email: [conduct@conda.org](mailto:conduct@conda.org)
+* contact [an individual committee member](#committee-membership) or [CoC event representative](#coc-representatives) to report an incident in confidence.
+
+Reports submitted via the form or committee email address are sent to the [full conda Code of Conduct Committee](#committee-membership).
+
+## What to Include in a Report
+
+Our ability to address any code of conduct breaches in a timely and effective manner is impacted by the amount of information you can provide, so, we ask you to include as much of the following information as you can**:
+
+- **Your contact info** (so we can get in touch with you if we need to follow up). This will be kept confidential. You can also file a report [anonymously](#anonymous-reporting).
+- The **approximate time and location of the incident** (please be as specific as possible).
+- **Identifying information** (e.g. name, nickname, screen name, physical description) of the individual whose behavior is being reported.
+- **Description of the behavior** (if reporting harassing language, please be specific about the words used), **your account of what happened**, and any available **supporting records** (e.g. email, GitHub issue, screenshots, etc.).
+- **Description of the circumstances/context** surrounding the incident.
+- Let us know **if the incident is ongoing**, and/or if this is part of an ongoing pattern of behavior.
+- Names and contact info, if possible, of **anyone else who witnessed** or was involved in this incident. (Did anyone else observe the incident?)
+- **Any other relevant information** you believe we should have.
+
+## Anonymous Reporting
+
+The reporting form supports anonymous incident reporting. Anonymous reporting works best when the behavior happened in a public space and was witnessed by many. If an incident is reported anonymously and was not witnessed by others, then the committee may be limited in what actions it can take and what it can report to the larger community. Nevertheless, the CoC Committee is still interested in receiving these reports. They are helpful when determining what we need to address as a community, and when looking for evidence of repeated behavior.
+
+## Conflicts of Interest
+
+Committee members are expected to recuse themselves if they have a conflict of interest, and are required to recuse themselves if they are the accused or the target of the reported behavior. In addition, the CoC Committee can [vote](#voting-and-decision-making) to remove a committee member from a case, if the committee feels that the member has a conflict of interest. This [vote](#voting-and-decision-making) requires a simple majority.
+
+If you are concerned about making a report that will be read by all committee members, you are strongly encouraged to contact [individual committee members](#committee-membership) directly.
+
+# Enforcement: What Happens After a Report is Filed?
+
+## Acknowledgment and Responding to Immediate Needs
+
+CoC Committee members and/or event staff will attempt to ensure your safety and help with any immediate needs. The CoC Committee will make every effort to **acknowledge receipt within 24 hours** (and we'll aim for much more quickly than that).
+
+## Reviewing the Report
+
+The CoC Committee will make all efforts to **review the incident within three days** and determine:
+
+- Whether this is an ongoing situation, or if there is a threat to anyone's physical safety
+- What happened
+- Whether this event constitutes a code of conduct violation
+- Who the bad actor was, if any
+
+## Contacting the Person Reported
+
+After the CoC Committee has had time to review and discuss the report, someone will attempt to contact the person who is the subject of the report to inform them of what has been reported about them. We will then ask that person for their account of what happened.
+
+## Response and Potential Consequences
+
+Once the CoC Committee has completed our investigation of the report, we will make a decision as to how to respond. The person making a report will not normally be consulted as to the proposed resolution of the issue, except insofar as we need to understand how to help them feel safe.
+
+Potential consequences for violating the conda Organization code of conduct include:
+
+- Nothing (if we determine that no violation occurred)
+- Private feedback or reprimand from the CoC Committee to the individual(s) involved
+- Warning the person to cease their behavior and that any further reports will result in sanctions
+- A public announcement that an incident occurred
+- Mediation (only if both reporter and reportee agree)
+- An imposed vacation (e.g. asking someone to "take a week off" from a mailing list)
+- A permanent or temporary ban from some or all the conda Organization spaces (mailing lists, GitHub repos, in-person events, etc.)
+- Assistance to the complainant with a report to other bodies, for example, institutional offices or appropriate law enforcement agencies
+- Removing a person from the conda Organization membership or other formal affiliation
+- Publishing an account of the harassment and calling for the resignation of the alleged harasser from their responsibilities (may be called for if the person is an event leader, or refuses to stand aside from the conflict of interest, or similar)
+- Any other response that the CoC Committee deems necessary and appropriate to the situation
+
+No one espousing views or values contrary to the standards of our code of conduct will be permitted to hold any position representing the conda Organization, including volunteer positions. The CoC Committee has the right and responsibility to remove, edit, or reject comments, commits, code, website edits, issues, and other contributions that are not aligned with this code of conduct.
+
+We aim to **respond within one week** to the original reporter with either a resolution or an explanation of why the situation is not yet resolved.
+
+We will contact the person who is the subject of the report to let them know what actions will be taken as a result of the report, if any.
+
+Our policy is to make sure that everyone aware of the initial incident is also made aware that official action has been taken, while still respecting the privacy of individuals. In addition, we will also usually [notify the community](#confidentiality-and-public-statements-to-the-community) that an incident has been reported, what type of incident it was, and what the response was, again respecting the privacy of individuals.
+
+## Appealing a Decision
+
+To appeal a decision of the CoC Committee, contact the [Committee Co-Chairs](#committee-membership), with your appeal. Please include as much detail as possible about why you are appealing the decision. The Co-Chairs will review the appeal, possibly consulting with the full Committee, and then issue a decision.
+
+# Timeline Summary:
+
+| Time | Event | Details |
+| ---- | ---- | ---- |
+| Within 24 Hours | Acknowledge | The CoC Committee will make every effort to **acknowledge receipt of a report within 24 hours**. |
+| Within 3 Days | Review | The CoC Committee aims to **review the incident within three days**. |
+| Within 1 Week | Resolve | We will **respond within one week** to the original reporter with either a resolution or an explanation of why the situation is not yet resolved. |
+
+# Voting and Decision Making
+
+Committee votes and decisions require both a minimum quorum size for the vote to be counted, and then a minimum percentage of cast affirmative votes to pass.
+
+Except where otherwise noted, votes require a quorum and a simple majority to pass:
+
+* Minimum Quorum:
+ * More than 50% of eligible committee members must vote.
+ * Eligibile members do not include those excluded because of [conflicts of interest](#conflicts-of-interest).
+* Affirmative vote threshold:
+ * More than 50% of the votes cast need to be affirmative to take action.
+
+# Committee Membership
+
+You can reach the entire CoC Committee by emailing [conduct@conda.org](mailto:conduct@conda.org).
+
+| Name | Employer / Funding | Steering Council Member | Current Term Ends |
+| ---- | ---- | ---- | --- |
+| [Eric Dill](https://github.com/ericdill) | [Anaconda](https://anaconda.com/) | | 2026-07-01 |
+| [Dasha Gurova](https://github.com/dashagurova) | [Anaconda](https://anaconda.com/) | | 2026-07-01 |
+| [Bianca Henderson](https://github.com/beeankha) | [Red Hat](https://redhat.com/) | | 2026-07-01 |
+| [Katherine Kinnaman](https://github.com/kathatherine) | [Anaconda](https://anadonda.com/) | | 2026-07-01 |
+| [Mahe Iram Khan](https://github.com/ForgottenProgramme) | [Anaconda](https://anaconda.com/) | | 2025-07-01 |
+| [Ken Odegard](https://github.com/kenodegard) | [Anaconda](https://anaconda.com/) | | 2025-07-01 |
+| [Crystal Soja](https://github.com/csoja), Co-Chair | [Anaconda](https://anaconda.com/) | | 2025-07-01 |
+| [Jaime Rodríguez-Guerra](https://github.com/jaimergp), Co-Chair | [Quansight](https://quansight.com/) | yes | 2025-07-01 |
+
+# Terms and New Members
+
+* Committee members are appointed for two year terms. Committee members can choose to renew their memberships.
+* Committee members can resign before their term ends.
+* Committee members can also be removed by a [simple majority vote](#voting-and-decision-making) from their fellow committee members.
+* New committee members are added by a simple majority vote as well.
+
+# Eligibility
+
+Anyone from the community who is interested and able to do CoC Committee work is eligible to be nominated for the committee. New committee members can be nominated by any community member, including nominating themselves.
+
+## Shared Funding
+
+Unlike the Steering Council, we are not limiting the number of Committee members who share a common source of funding. However, if a report involves someone who shares funding with CoC Committee members, then the remainder of the committee may vote to exclude some or all Committee members with that same funding, even if that excludes a majority of the CoC Committee. This should be done only if the separately funded Committee members feel that the common funding is interfering with decision making.
+
+Note: This requires tracking the funding sources of CoC Committee members.
+
+## Overlap with Steering Council Membership
+
+Committee members can also be on the conda Organization Steering Council. However, Steering Council members have to make up less than 50% of the Code of Conduct Committee.
+
+# Updating this Code of Conduct
+
+The conda Organization's Code of Conduct can be updated by a [simple majority vote](#voting-and-decision-making) of the CoC Committee.
+
+
+# License
+
+This code of conduct is based on the [NumFOCUS code of conduct template](https://github.com/numfocus/numfocus/blob/8759e21481552f213489e3718979ccecf68e9ead/manual/numfocus-coc.md) as it existed on 2022/03/08 (which is the 2019/11/20 version). Several added sections are based on the [Galaxy Community Code of Conduct](https://galaxyproject.org/community/coc/).
+
+The NumFOCUS code of conduct template was itself adapted from numerous sources, including the [*Geek Feminism wiki, created by the Ada Initiative and other volunteers, which is under a Creative Commons Zero license*](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy), the [*Contributor Covenant version 1.2.0*](http://contributor-covenant.org/version/1/2/0/), the [*Bokeh Code of Conduct*](https://github.com/bokeh/bokeh/blob/master/CODE_OF_CONDUCT.md), the [*SciPy Code of Conduct*](https://github.com/jupyter/governance/blob/master/conduct/enforcement.md), the [*Carpentries Code of Conduct*](https://docs.carpentries.org/topic_folders/policies/code-of-conduct.html#enforcement-manual), and the [*NeurIPS Code of Conduct*](https://neurips.cc/public/CodeOfConduct).
+
+**The conda Organization Code of Conduct is licensed under the [Creative Commons Attribution 3.0 Unported License](https://creativecommons.org/licenses/by/3.0/).**
diff --git a/HOW_WE_USE_GITHUB.md b/HOW_WE_USE_GITHUB.md
index 46a13ecd..8b035792 100644
--- a/HOW_WE_USE_GITHUB.md
+++ b/HOW_WE_USE_GITHUB.md
@@ -1,47 +1,45 @@
+
+# How We Use GitHub
+
[conda-org]: https://github.com/conda
-[sub-team]: https://github.com/conda-incubator/governance#sub-teams
-[project-planning]: https://github.com/orgs/conda/projects/2/views/11
-[project-sorting]: https://github.com/orgs/conda/projects/2/views/11
-[project-support]: https://github.com/orgs/conda/projects/2/views/12
-[project-backlog]: https://github.com/orgs/conda/projects/2/views/13
-[project-in-progress]: https://github.com/orgs/conda/projects/2/views/14
+[project-refinement]: https://github.com/orgs/conda/projects/22/views/14
+[project-backlog]: https://github.com/orgs/conda/projects/22/views/2
+[project-current-sprint]: https://github.com/orgs/conda/projects/22/views/10
+[project-review]: https://github.com/orgs/conda/projects/16
[docs-toc]: https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/
-[docs-actions]: https://docs.github.com/en/actions
[docs-saved-reply]: https://docs.github.com/en/get-started/writing-on-github/working-with-saved-replies/creating-a-saved-reply
-[docs-commit-signing]: https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
[infrastructure]: https://github.com/conda/infrastructure
[workflow-sync]: https://github.com/conda/infrastructure/blob/main/.github/workflows/sync.yml
[labels-global]: https://github.com/conda/infrastructure/blob/main/.github/global.yml
-[workflow-cla]: /.github/workflows/cla.yml
-[workflow-issues]: /.github/workflows/issues.yml
-[workflow-labels]: /.github/workflows/labels.yml
-[workflow-lock]: /.github/workflows/lock.yml
-[workflow-project]: /.github/workflows/project.yml
-[workflow-stale]: /.github/workflows/stale.yml
-[labels-local]: /.github/labels.yml
-[labels-page]: ../../labels
-
-# How We Use GitHub
+[workflow-cla]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/cla.yml
+[workflow-issues]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/issues.yml
+[workflow-labels]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/labels.yml
+[workflow-lock]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/lock.yml
+[workflow-project]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/project.yml
+[workflow-stale]: https://github.com/conda/issue-tracker/blob/main/.github/workflows/stale.yml
+[labels-local]: https://github.com/conda/issue-tracker/blob/main/.github/labels.yml
+[labels-page]: https://github.com/conda/issue-tracker/labels
This document seeks to outline how we as a community use GitHub Issues to track bugs and feature requests while still catering to development practices & project management (_e.g._, release cycles, feature planning, priority sorting, etc.).
**Topics:**
- - [What is "Issue Sorting"?](#what-is-issue-sorting)
- - [Issue Sorting Procedures](#issue-sorting-procedures)
- - [Commit Signing](#commit-signing)
- - [Types of Issues](#types-of-issues)
- - [Standard Issue](#standard-issue)
- - [Epics](#epics)
- - [Spikes](#spikes)
- - [Working on Issues](#working-on-issues)
+- [What is "Issue Sorting"?](#what-is-issue-sorting)
+- [Labeling](#labeling)
+- [Types of Issues](#types-of-issues)
+ - [Standard Issue](#standard-issue)
+ - [Epics](#epics)
+ - [Spikes](#spikes)
+- [Working on Issues](#working-on-issues)
+- [Development Processes](#development-processes)
+- [Code Review and Merging](#code-review-and-merging)
> [!NOTE]
> This document is written in the style of an FAQ. For easier navigation, use [GitHub's table of contents feature][docs-toc].
@@ -55,31 +53,27 @@ This document seeks to outline how we as a community use GitHub Issues to track
```mermaid
flowchart LR
- subgraph flow_sorting [Issue Sorting]
- board_sorting{{Sorting}}
- board_support{{Support}}
-
- board_sorting<-->board_support
+ subgraph flow_sorting [Issue Sorting in Issue Tracker]
+ state_sorting{{Maintainer sorting}}
end
- subgraph flow_refinement [Refinement]
+ subgraph flow_roadmap [Roadmap Board]
+ board_refinement{{Refinement}}
board_backlog{{Backlog}}
- board_backlog-- refine -->board_backlog
- end
-
- subgraph flow_progress [In Progress]
- board_progress{{In Progress}}
+ board_refinement-->board_backlog
+ board_backlog-- reprioritize -->board_backlog
+ board_progress{{Current Sprint - In Progress}}
end
state_new(New Issues)
state_closed(Closed)
- state_new-->board_sorting
- board_sorting-- investigated -->board_backlog
- board_sorting-- duplicates, off-topic -->state_closed
- board_support-- resolved, unresponsive -->state_closed
+ state_new-->state_sorting
+ state_sorting-- accepted for work -->board_refinement
+ state_sorting-- duplicate, off-topic, support resolved -->state_closed
board_backlog-- pending work -->board_progress
+ board_refinement-- not actionable -->state_closed
board_backlog-- resolved, irrelevant -->state_closed
board_progress-- resolved -->state_closed
```
@@ -95,109 +89,51 @@ At the most basic "bird's eye view" level, sorted issues will fall into the cate
At its core, sorting enables new issues to be placed into these four categories, which helps to ensure that they will be processed at a velocity similar to or exceeding the rate at which new issues are coming in. One of the benefits of actively sorting issues is to avoid engineer burnout and to make necessary work sustainable; this is done by eliminating a never-ending backlog that has not been reviewed by any maintainers.
-There will always be broad-scope design and architecture implementations that the maintainers will be interested in pursuing; by actively organizing issues, the sorting engineers will be able to more easily track and tackle both specific and big-picture goals.
+There will always be broad-scope design and architecture implementations that the maintainers will be interested in pursuing; by actively organizing issues, they will be able to more easily track and tackle both specific and big-picture goals.
### Who does the sorting?
-Sorting engineers are a conda governance [sub-team][sub-team]; they are a group of community members who are responsible for making decisions regarding closing issues and setting feature work priorities, among other sorting-related tasks.
+Core maintainers help with sorting issues, making decisions regarding closing issues and setting feature work priorities, among other sorting-related tasks.
-### How do items show up for sorting?
+### How does issue sorting and board intake work?
-New issues that are opened in any of the repositories in the [conda GitHub organization][conda-org] will show up in the "Sorting" tab of the [Planning project][project-planning]. There are two [GitHub Actions][docs-actions] workflows utilized for this purpose; [`.github/workflows/issues.yml`][workflow-issues] and [`.github/workflows/project.yml`][workflow-project].
-
-The GitHub Actions in the [`conda/infrastructure`][infrastructure] repository are viewed as canonical; the [`.github/workflows/sync.yml` workflow][workflow-sync] sends out any modifications to other `conda` repositories from there.
-
-### What is done about the issues in the "Sorting" tab?
-
-Issues in the ["Sorting" tab of the project board][project-sorting] are considered ready for the following procedures:
+New issues that are opened in any of the repositories in the [conda GitHub organization][conda-org] are reviewed in the repository issue tracker first. During sorting in the issue tracker, issues are reviewed for the following outcomes:
- Mitigation via short-term workarounds and fixes
- Redirection to the correct project
- Determining if support can be provided for errors and questions
- Closing out of any duplicate/off-topic issues
-The sorting engineers on rotation are not seeking to _resolve_ issues that arise. Instead, the goal is to understand the issue and to determine whether it is legitimate, and then to collect as much relevant information as possible so that the maintainers can make an informed decision about the appropriate resolution schedule.
+The core maintainers are not seeking to _resolve_ issues that arise. Instead, the goal is to understand the issue and to determine whether it is legitimate, and then to collect as much relevant information as possible so that the maintainers can make an informed decision about the appropriate resolution schedule.
-Issues will remain in the ["Sorting" tab][project-sorting] as long as the issue is in an investigatory phase (_e.g._, querying the user for more details, asking the user to attempt other workarounds, other debugging efforts, etc.) and are likely to remain in this state the longest, but should still be progressing over the course of 1-2 weeks.
+Issues can remain in this investigatory phase (_e.g._, querying the user for more details, asking the user to attempt other workarounds, other debugging efforts, etc.) and are likely to remain in this state the longest, but should still be progressing over the course of 1-2 weeks.
-For more information on the sorting process, see [Issue Sorting Procedures](#issue-sorting-procedures).
+Items are added to the [Refinement tab of the Roadmap Board][project-refinement] once sorting has concluded and the core maintainer has enough information to make a decision about the appropriate resolution schedule for the issue. Newly opened pull requests are automatically added to the [Review board][project-review] by [`.github/workflows/project.yml`][workflow-project].
-### When do items move out of the "Sorting" tab?
-
-Items move out of the ["Sorting" tab][project-sorting] once the investigatory phase described in [What is done about the issues in the "Sorting" tab?](#what-is-done-about-the-issues-in-the-sorting-tab) has concluded and the sorting engineer has enough information to make a decision about the appropriate resolution schedule for the issue. The additional tabs in the project board that the issues can be moved to include the following:
-
-- **"Support"** - Any issue in the ["Support" tab of the Planning board][project-support] is a request for support and is not a feature request or a bug report. Add the [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) label to move an issue to this tab.
-- **"Backlog"** - The issue has revealed a bug or feature request. We have collected enough details to understand the problem/request and to reproduce it on our own. These issues have been moved into the [Backlog tab of the Planning board][project-backlog] at the end of the sorting rotation during Refinement. Add the [`backlog`](https://github.com/conda/infrastructure/labels/backlog) label to move an issue to this tab.
-- **"Closed"** - The issue was closed due to being a duplicate, being redirected to a different project, was a user error, a question that has been resolved, etc.
+Issues that are not accepted for planned work are closed instead (_e.g._ duplicates, redirects, user errors, resolved support questions, etc.).
### Where do work issues go after being sorted?
-Once issues are deemed ready to be worked on, they will be moved to the ["Backlog" tab of the Planning board][project-backlog]. Once actively in progress, the issues will be moved to the ["In Progress" tab of the Planning board][project-in-progress] and then closed out once the work is complete.
+Once issues are accepted for work, they are added to the ["Refinement" tab of the Roadmap Board][project-refinement]. After refinement and prioritization, issues move to ["Backlog"][project-backlog] and then to ["Current Sprint"][project-current-sprint] when actively being worked. Issues are closed once the work is complete.
### What is the purpose of having a "Backlog"?
-Issues are "backlogged" when they have been sorted but not yet earmarked for an upcoming release.
+Issues are "backlogged" when they have been accepted and refined but are not yet planned into the current sprint.
### What automation procedures are currently in place?
Global automation procedures synced out from the [`conda/infrastructure`][infrastructure] repo include:
-- [Marking of issues and pull requests as stale][workflow-stale], resulting in:
- - issues marked as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) being labeled stale after 21 days of inactivity and being closed after 7 further days of inactivity (that is, closed after 30 inactive days total)
- - all other inactive issues (not labeled as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport) being labeled stale after 365 days of inactivity and being closed after 30 further days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
- - all inactive pull requests being labeled stale after 365 days of inactivity and being closed after 30 further days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
+- [Marking/Closing stale issues and pull requests][workflow-stale]:
+ - https://github.com/conda/issue-tracker/labels/type%3A%3Asupport issues are labeled as stale after 21 days of inactivity and are closed after 7 more days of inactivity (that is, closed after 30 inactive days total)
+ - non https://github.com/conda/issue-tracker/labels/type%3A%3Asupport issues are labeled as stale after 365 days of inactivity and are closed after 30 more days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
+ - all pull requests are labeled as stale after 365 days of inactivity and are closed after 30 more days of inactivity (that is, closed after an approximate total of 1 year and 1 month of inactivity)
- [Locking of closed issues and pull requests with no further activity][workflow-lock] after 365 days
-- [Adding new issues and pull requests to the respective project boards][workflow-project]
-- [Indicating an issue is ready for the sorting engineer's attention][workflow-issues] by toggling [`pending::feedback`](https://github.com/conda/infrastructure/labels/pending%3A%3Afeedback) with [`pending::support`](https://github.com/conda/infrastructure/labels/pending%3A%3Asupport) after a contributor leaves a comment
-- [Verifying that contributors have signed the CLA][workflow-cla] before allowing pull requests to be merged; if the contributor hasn't signed the CLA previously, merging is be blocked until a manual review can be done
+- [Adding new pull requests to the Review board][workflow-project]
+- [Indicating an issue is ready for a maintainer's attention][workflow-issues] by toggling https://github.com/conda/issue-tracker/labels/pending%3A%3Afeedback with https://github.com/conda/issue-tracker/labels/pending%3A%3Asupport after a contributor leaves a comment
+- [Verifying that contributors have signed the CLA][workflow-cla] before allowing pull requests to be merged; if the contributor hasn't signed the CLA previously, merging is blocked until a manual review can be done
- [Syncing out templates, labels, workflows, and documentation][workflow-sync] from [`conda/infrastructure`][infrastructure] to the other repositories
-## Issue Sorting Procedures
-
-### How are issues sorted?
-
-Issues in the ["Sorting" tab of the Planning board][project-sorting] are reviewed by issue sorting engineers, who take rotational sorting shifts. In the process of sorting issues, engineers label the issues and move them to the other tabs of the project board for further action.
-
-Issues that require input from multiple members of the sorting team will be brought up during refinement meetings in order to understand how those particular issues fit into the short- and long-term roadmap. These meetings enable the sorting engineers to get together to collectively prioritize issues, earmark feature requests for specific future releases (versus a more open-ended backlog), tag issues as ideal for first-time contributors, as well as whether or not to close/reject specific feature requests.
-
-### How does labeling work?
-
-Labeling is a very important means for sorting engineers to keep track of the current state of an issue with regards to the asynchronous nature of communicating with users. Utilizing the proper labels helps to identify the severity of the issue as well as to quickly understand the current state of a discussion.
-
-Each label has an associated description that clarifies how the label should be used. Hover on the label to see its description. Label colors are used to distinguish labels by category.
-
-Generally speaking, labels with the same category are considered mutually exclusive, but in some cases labels sharing the same category can occur concurrently, as they indicate qualifiers as opposed to types. For example, we may have the following types, [`type::bug`](https://github.com/conda/infrastructure/labels/type%3A%3Abug), [`type::feature`](https://github.com/conda/infrastructure/labels/type%3A%3Afeature), and [`type::documentation`](https://github.com/conda/infrastructure/labels/type%3A%3Adocumentation), where for any one issue there would be _at most_ **one** of these to be defined (_i.e._ an issue should not be a bug _and_ a feature request at the same time). Alternatively, with issues involving specific operating systems (_i.e._, [`os::linux`](https://github.com/conda/infrastructure/labels/os%3A%3Alinux), [`os::macos`](https://github.com/conda/infrastructure/labels/os%3A%3Amacos), and [`os::windows`](https://github.com/conda/infrastructure/labels/os%3A%3Awindows)), an issue could be labeled with one or more, depending on the system(s) the issue occurs on.
-
-Please note that there are also automation policies in place that are affected by labeling. For example, if an issue is labeled as [`type::support`](https://github.com/conda/infrastructure/labels/type%3A%3Asupport), that issue will be marked [`stale`](https://github.com/conda/infrastructure/labels/stale) after 21 days of inactivity and auto-closed after seven more days without activity (30 inactive days total), which is earlier than issues without this label. See [What automation procedures are currently in place?](#what-automation-procedures-are-currently-in-place) for more details.
-
-### What labels are required for each issue?
-
-At minimum, both `type` and `source` labels should be specified on each issue before moving it from the "Sorting" tab to the "Backlog" tab. All issues that are bugs should also be tagged with a `severity` label.
-
-The `type` labels are exclusive of each other: each sorted issue should have exactly one `type` label. These labels give high-level information on the issue's classification (_e.g._, bug, feature, tech debt, etc.)
-
-The `source` labels are exclusive of each other: each sorted issue should have exactly one `source` label. These labels give information on the sub-group to which the issue's author belongs (_e.g._, a partner, a frequent contributor, the wider community, etc.). Through these labels, maintainers gain insight into how well we're meeting the needs of various groups.
-
-The `severity` labels are exclusive of each other and, while required for the [`type::bug`](https://github.com/conda/infrastructure/labels/type%3A%bug) label, they can also be applied to other types to indicate demand or need. These labels help us to prioritize our work. Severity is not the only factor for work prioritization, but it is an important consideration.
-
-Please review the descriptions of the `type`, `source`, and `severity` labels on the [labels page][labels-page] prior to use.
-
-### How are new labels defined?
-
-Labels are defined using a scoped syntax with an optional high-level category (_e.g._, `source`, `tag`, `type`, etc.) and a specific topic, much like the following:
-
-- `[topic]`
-- `[category::topic]`
-- `[category::topic-phrase]`
-
-This syntax helps with issue sorting enforcement, as it helps to ensure that sorted issues are, at minimum, categorized by type and source.
-
-There are a number of labels that have been defined for the different repositories. In order to create a streamlined sorting process, label terminologies are standardized using similar (if not the same) labels.
-
-### How are new labels added?
-
-New **global** labels (_i.e._, labels that apply equally to all repositories within the conda GitHub organization) are added to [`conda/infrastructure`][infrastructure]'s [`.github/global.yml` file][labels-global]; new **local** labels (_i.e._, labels specific to particular repositories) are added to each repository's [`.github/labels.yml` file][labels-local]. All new labels should follow the labeling syntax described in ["How are new labels defined?"](#how-are-new-labels-defined). Global labels are combined with any local labels and these aggregated labels are used by the [`.github/workflows/labels.yml` workflow][workflow-labels] to synchronize the labels available for the repository.
-
### Are there any templates to use as responses for commonly-seen issues?
Some of the same types of issues appear regularly (_e.g._, issues that are duplicates of others, issues that should be filed in the Anaconda issue tracker, errors that are due to a user's specific setup/environment, etc.).
@@ -213,91 +149,105 @@ Below are some boilerplate responses for the most commonly-seen issues to be sor
This is a duplicate of [link to primary issue]; please feel free to continue the discussion there.
-> [!WARNING]
-> Apply the https://github.com/conda/infrastructure/labels/duplicate label to the issue being closed and https://github.com/conda/infrastructure/labels/duplicate%3A%3Aprimary to the original issue.
+
+
+> **Warning**
+> Apply the https://github.com/conda/issue-tracker/labels/duplicate label to the issue being closed and https://github.com/conda/issue-tracker/labels/duplicate%3A%3Aprimary to the original issue.
-Requesting an Uninstall/Reinstall of conda
+Anaconda Products
+Thank you for filing this issue! Unfortunately, this is off-topic for this repo because it is related to an Anaconda product.
+If you are encountering issues with Anaconda products or services, you have several options for receiving community
+support:
-Please uninstall your current version of `conda` and reinstall the latest version.
-Feel free to use either the [miniconda](https://docs.anaconda.com/free/miniconda/)
-or [anaconda](https://www.anaconda.com/products/individual) installer,
-whichever is more appropriate for your needs.
+- [Anaconda community forums](https://community.anaconda.cloud)
+- [Anaconda issue tracker on GitHub](https://github.com/ContinuumIO/anaconda-issues/issues)
+
+
+> **Warning**
+> Apply the https://github.com/conda/issue-tracker/labels/off-topic label to these issues before closing them out.
+
-Redirect to Anaconda Issue Tracker
+General Off Topic
-
+Unfortunately, this issue is outside the scope of support we offer via GitHub or is not directly related to this project.
+Community support can be found elsewhere, though, and we encourage you to explore the following options:
-Thank you for filing this issue! Unfortunately, this is off-topic for this repo.
-If you are still encountering this issue please reopen in the
-[Anaconda issue tracker](https://github.com/ContinuumIO/anaconda-issues/issues)
-where `conda` installer/package issues are addressed.
+- [Conda discourse forum](https://conda.discourse.group/)
+- [Community chat channels](https://conda.org/community#chat)
+- [Stack Overflow posts tagged "conda"](https://stackoverflow.com/questions/tagged/conda)
-> [!WARNING]
-> Apply the https://github.com/conda/infrastructure/labels/off-topic label to these issues before closing them out.
+
+
+> **Warning**
+> Apply the https://github.com/conda/issue-tracker/labels/off-topic label to these issues before closing them out.
-
-Redirecting to Nucleus Forums
+In order to not have to manually type or copy/paste the above repeatedly, note that it's possible to add text for the most commonly-used responses via [GitHub's "Add Saved Reply" option][docs-saved-reply].
-
-
+## Labeling
-Unfortunately, this issue is outside the scope of support we offer via GitHub;
-if you continue to experience the problems described here,
-please post details to the [Nucleus forums](https://community.anaconda.cloud/).
-
+This section covers the labels and conventions used during issue sorting.
-> [!WARNING]
-> Apply the https://github.com/conda/infrastructure/labels/off-topic label to these issues before closing them out.
+### How does labeling work?
-
+Labeling is a very important means for core maintainers to keep track of the current state of an issue with regards to the asynchronous nature of communicating with users. Utilizing the proper labels helps to identify the severity of the issue as well as to quickly understand the current state of a discussion.
-
-Slow solving of conda environment
+Each label has an associated description that clarifies how the label should be used. Hover on the label to see its description. Label colors are used to distinguish labels by category.
-
-
-Hi [@username],
+Generally speaking, labels with the same category are considered mutually exclusive, but in some cases labels sharing the same category can occur concurrently, as they indicate qualifiers as opposed to types. For example, we may have the following types, https://github.com/conda/issue-tracker/labels/type%3A%3Abug, https://github.com/conda/issue-tracker/labels/type%3A%3Afeature, and https://github.com/conda/issue-tracker/labels/type%3A%3Adocumentation, where for any one issue there would be _at most_ **one** of these to be defined (_i.e._ an issue should not be a bug _and_ a feature request at the same time). Alternatively, with issues involving specific operating systems (_i.e._, https://github.com/conda/issue-tracker/labels/os%3A%3Alinux, https://github.com/conda/issue-tracker/labels/os%3A%3Amacos, and https://github.com/conda/issue-tracker/labels/os%3A%3Awindows), an issue could be labeled with one or more, depending on the system(s) the issue occurs on.
-Thanks for voicing your concern about the performance of the classic dependency solver. To fix this, our official recommendation is using the new default "conda-libmamba-solver" instead of the classic solver (more information about the "conda-libmamba-solver" can be found here: https://conda.github.io/conda-libmamba-solver/getting-started/).
+Please note that there are also automation policies in place that are affected by labeling. For example, if an issue is labeled as https://github.com/conda/issue-tracker/labels/type%3A%3Asupport, that issue will be marked https://github.com/conda/issue-tracker/labels/stale after 21 days of inactivity and auto-closed after seven more days without activity (30 inactive days total), which is earlier than issues without this label. See [What automation procedures are currently in place?](#what-automation-procedures-are-currently-in-place) for more details.
-In most cases "conda-libmamba-solver" should be significantly faster than the "classic" solver. We hope it provides you with a much better experience going forward.
-
+### What labels are required for each issue?
-
+At minimum, both `type` and `source` labels should be specified on each issue before adding it to the "Refinement" tab of the Roadmap Board. All issues that are bugs should also be tagged with a `severity` label.
+The `type` labels are exclusive of each other: each sorted issue should have exactly one `type` label. These labels give high-level information on the issue's classification (_e.g._, bug, feature, tech debt, etc.)
-In order to not have to manually type or copy/paste the above repeatedly, note that it's possible to add text for the most commonly-used responses via [GitHub's "Add Saved Reply" option][docs-saved-reply].
+The `source` labels are exclusive of each other: each sorted issue should have exactly one `source` label. These labels give information on the sub-group to which the issue's author belongs (_e.g._, a partner, a frequent contributor, the wider community, etc.). Through these labels, maintainers gain insight into how well we're meeting the needs of various groups.
+
+The `severity` labels are exclusive of each other and, while required for the https://github.com/conda/issue-tracker/labels/type%3A%3Abug label, they can also be applied to other types to indicate demand or need. These labels help us to prioritize our work. Severity is not the only factor for work prioritization, but it is an important consideration.
+
+Please review the descriptions of the `type`, `source`, and `severity` labels on the [labels page][labels-page] prior to use.
+
+### How are new labels defined?
+
+Labels are defined using a scoped syntax with an optional high-level category (_e.g._, `source`, `tag`, `type`, etc.) and a specific topic, much like the following:
+
+- `[topic]`
+- `[category::topic]`
+- `[category::topic-phrase]`
-## Commit Signing
+This syntax helps with issue sorting enforcement, as it helps to ensure that sorted issues are, at minimum, categorized by type and source.
-For all conda maintainers, we require commit signing and strongly recommend it for all others wishing to contribute to conda
-related projects. More information about how to set this up within GitHub can be found here:
+There are a number of labels that have been defined for the different repositories. In order to create a streamlined sorting process, label terminologies are standardized using similar (if not the same) labels.
-- [GitHub's signing commits docs][docs-commit-signing]
+### How are new labels added?
+
+New **global** labels (_i.e._, labels that apply equally to all repositories within the conda GitHub organization) are added to [`conda/infrastructure`][infrastructure]'s [`.github/global.yml` file][labels-global]; new **local** labels (_i.e._, labels specific to particular repositories) are added to each repository's [`.github/labels.yml` file][labels-local]. All new labels should follow the labeling syntax described in ["How are new labels defined?"](#how-are-new-labels-defined). Global labels are combined with any local labels and these aggregated labels are used by the [`.github/workflows/labels.yml` workflow][workflow-labels] to synchronize the labels available for the repository.
## Types of Issues
### Standard Issue
-TODO
+Standard issues represent typical bug reports, feature requests, or other work items that have a clear definition and expected outcome.
### Epics
-TODO
+Epics are large work items that can be broken down into smaller, more manageable issues. They typically represent major features or significant changes that span multiple iterations or releases. Relate the smaller issues to the epic using the sub-issues feature in GitHub.
### Spikes
@@ -332,3 +282,76 @@ If you do **not** have permissions, please indicate that you are working on an i
If you are assigned to an issue but will not be able to continue work on it, please comment to indicate that you will no longer be working on it and press `unassign me` next to your username in the `Assignees` section of the issue page (top right).
If you **do** have permissions, please assign yourself to the issue by pressing `assign myself` under the `Assignees` section of the issue page (top right).
+
+## Development Processes
+
+The following are practices the conda organization encourages for feature
+development. While we recommend projects under the conda organization adopt
+these practices, they are not strictly required.
+
+### How should we approach feature development?
+
+For new features, first open an issue if one doesn’t exist. Once the feature request
+has been accepted (indicated by the issue's status transitioning from "Sorting" to
+"Refinement"), create a specification to gather early feedback. This can include
+mockups, API/command references, a written plan in the issue, and sample CLI
+arguments (without functionality).
+
+### What is our change process?
+
+For larger features, break down the work into smaller, manageable issues
+that are added to the backlog. As long as a feature remains on the roadmap
+or backlog, do not create long-lived feature branches that span multiple
+pull requests. Instead, you should integrate small slices of an overall
+feature directly into the main branch to avoid complex integration challenges.
+
+### Should we make unrelated changes at the same time?
+
+When making changes, try to follow the Campsite Rule to leave things better
+than when you found them. You should enhance the code you encounter, even if
+primary goal is unrelated. This could involve refactoring small sections,
+improving readability, or fixing minor bugs.
+
+## Code Review and Merging
+
+### What are the review requirements?
+
+#### Standard Review
+
+Most code changes require one reviewer from someone on the maintainer team for
+the repository. Instead of waiting for someone on the team to review it,
+directly requesting a review from the person you previously identified to work
+with is preferred to optimize teamwork. If you paired with them during
+development, continuous review counts as this requirement.
+
+#### Second Review
+
+Required only when the code author or the first reviewer feels like it is
+necessary to get another set of eyes on a proposed change. In this case, they
+add someone specific through GitHub's Request Review feature with a comment on
+what they want the person to look for.
+
+### What are the code review best practices?
+
+If you are conducting a review, adhere to these best practices:
+
+- Provide comprehensive feedback in the first review to minimize review rounds
+- Reserve Request Changes for blocking issues (bugs or other major problems) —
+ Select Comment for suggestions and improvements
+- Follow-up reviews should focus on whether requested changes resolve original
+ comments
+- Code should be production-ready and maintainable when merged, but doesn't
+ need to be perfect
+- If providing feedback outside the core review focus (nitpicks, tips,
+ suggestions), clearly mark these as non-blocking comments that don't need to
+ be addressed before merging.
+
+### How do we merge code?
+
+If you are the approving reviewer (typically the first reviewer, or the second
+reviewer when needed) and you have completed your review and approved the
+changes, you should merge the code immediately to maintain development
+velocity.
+
+Normally, we use squash and merge to keep a clean git history. If you are
+merging a pull request, help ensure that the pull request title is updated.
diff --git a/history.py b/history.py
index 9820da4d..711b7649 100755
--- a/history.py
+++ b/history.py
@@ -6,6 +6,7 @@
Normally this should not be used. This is ideally only used to generate the initial
historical data points for repos that have not been previously tracked.
"""
+
import argparse
import json
import time