Merge branch 'main' into dcmcand-optimize-docker-files

docusaurus-docs/community/contribute/contribute-code.md

@@ -0,0 +1,7 @@
+---
+description: Contribute to conda-store's codebase
+---
+
+# Contribute code
+
+<!-- TODO -->

docusaurus-docs/community/contribute/contribute-docs.md

@@ -2,4 +2,6 @@
 description: Contribute to conda-store's documentation
 ---
 
-# Contribute to conda-store's documentation
+# Contribute documentation
+
+<!-- TODO -->

docusaurus-docs/community/contribute/index.md

@@ -1,8 +1,9 @@
 ---
-description: Contribute
+sidebar_position: 2
+description: Guidelines for conda-store contributors
 ---
 
-# Contribute
+# Contribution guidelines
 
 import DocCardList from '@theme/DocCardList';
 import {useCurrentSidebarCategory} from '@docusaurus/theme-common';

docusaurus-docs/community/contribute/issues.md

@@ -0,0 +1,71 @@
+---
+description: Best practices for opening issues
+---
+
+# Create and improve issues
+
+## Submit bug report or feature request
+
+The conda-store issue trackers are the preferred channel for bug reports, documentation requests, and submitting pull requests.
+
+To resolve your issue, please select the appropriate category and follow the prompts to provide as much information as
+possible:
+
+- **Bug Report:** When something is not working as expected and documented
+- **Feature request:** Request new enhancements to conda-store
+- **Usage question:** Questions about how to use conda-store
+- **General issue:** Anything that doesn't fit the above categories
+
+## Best practices
+
+When opening an issue, use a **descriptive title** and include all relevant details about your bug and environment (operating system, Python version, conda-store version, etc.). Our issue template helps you remember the most important details to include.
+
+A few more tips:
+
+- **Describing your issue**: Try to provide as many details as possible. What exactly goes wrong? How is it failing?
+  Is there an error? "XY doesn't work" usually isn't that helpful for tracking down problems.
+  Provide clear instructions for how to reproduce your issue.
+  Always remember to include the code you ran and if possible,
+  extract only the relevant parts and don't dump your entire script.
+  You can also add screenshots and recordings of the issue.
+  This is essential for the development team to triage, prioritize, and resolve your issue.
+
+- **Getting info about your conda-store installation and environment**: You can use the command line interface to print details and even format them as Markdown to copy-paste into GitHub issues.
+
+- **Sharing long blocks of code or logs**: If you need to include long code, logs or trace backs, you can wrap them in `<details>` and `</details>`.
+  This collapses the content, so it only becomes visible on click, making the issue easier to read and follow.
+
+:::tip
+See this page for an overview of the [system we use to tag our issues and pull requests][github-conventions].
+:::
+
+## Suggested workflow
+
+If an issue is affecting you, start at the top of this list and complete as many tasks on the list as you can:
+
+1. Check the issue tracker, if there is an open issue for this same problem, add a reaction or more details to the issue
+   to indicate that it’s affecting you (tip: make sure to also check the open pull requests for ongoing work).
+2. If there is an open issue, and you can add more detail, write a comment describing how the problem is affecting you (tip: learn to improve issues in the next section),
+   OR if you can, write up a work-around or improvement for the issue.
+3. If there is not an issue, write the most complete description of what’s happening including reproduction steps.
+4. [Optional] - Offer to help fix the issue (and it is totally expected that you ask for help; open-source maintainers want to help contributors).
+5. [Optional] - If you decide to help to fix the issue, deliver a well-crafted, tested PR.
+
+## Improve existing issues
+
+Improving issues increases their chances of being successfully resolved. A third party can give useful feedback or even add comments on the issue.
+
+The following actions are typically useful:
+
+- Add missing elements that are blocking progress such as code samples to reproduce the problem.
+- Suggest better use of code formatting.
+- Suggest reformulating the title and description to make them more explicit about the problem to be solved.
+- Link to related issues or discussions while briefly describing how they are related, for instance “See also #xyz for a similar attempt at this” or “See also #xyz where the same thing happened in another cloud provider" provides context and helps the discussion.
+- Summarize long discussions on issues to help new and existing contributors quickly understand the background, current status, and course of action for the issue.
+
+You can further [contribute to triaging efforts with these guidelines][triage].
+
+<!-- Internal links -->
+
+[github-conventions]: /community/maintenance/github-conventions
+[triage]: /community/maintenance/triage

docusaurus-docs/community/contribute/contribute-core.md → docusaurus-docs/community/contribute/testing.md

@@ -2,4 +2,6 @@
 description: Contribute to conda-store
 ---
 
-# Contribute to conda-store
+# Run test suite
+
+<!-- TODO -->

docusaurus-docs/community/introduction.md

@@ -4,4 +4,75 @@ title: Introduction
 description: Community documentation
 ---
 
-# conda-store community
+# Welcome to conda-store!
+
+conda-store is a set of open source tools for managing data science environments in collaborative teams. It provides flexible-yet-reproducible environments and a user-friendly graphical interface, while enforcing best practices throughout the environment's life cycle.
+
+## Projects
+
+conda-store consists of three projects which are developed on separate GitHub repositories. The each have separate spaces on our documentation site as well:
+
+- [conda-store][conda-store-docs]: core library that provides all the key features through a REST API and CLI
+- [conda-store-ui][conda-store-ui-docs]: web application (frontend) for accessing all the conda-store features
+- [jupyterlab-conda-store][jupyterlab-conda-store-docs]: extension to access conda-store-ui within JupyterLab
+
+:::note
+The term "conda-store" is heavily overloaded, it can refer to the overall set of projects, the core repository, or the package based on context.
+If the meaning is unclear in a discussion, don't hesitate to ask the people involved to clarify.
+:::
+
+## Code of Conduct
+
+The conda-store development team pledges to create a welcoming, supportive, and harassment-free space for everyone. All conda-store spaces, including GitHub conversations and video meetings, are covered by the [conda organization code of conduct](https://github.com/conda-incubator/governance/blob/main/CODE_OF_CONDUCT.md).
+
+## Governance
+
+As a [federated project](https://github.com/conda-incubator/governance/tree/main#federated-projects) under the [conda-incubator organization](https://github.com/conda-incubator), conda-store follows the [conda-incubator governance](https://github.com/conda-incubator/governance/tree/main#conda--conda-incubator-governance). The [conda-store development team (documented through GitHub Teams)](https://github.com/orgs/conda-incubator/teams) makes all project decisions using a [consent-based approach](https://www.sociocracyforall.org/consent-decision-making/) on the issue tracker or in team meetings.
+
+## Support
+
+conda-store's issue trackers are the best way to reach the conda-store development team. If you have any usage or contribution questions, open an issue on the corresponding repository following the [issue creation guidelines][issues]:
+
+* [conda-store](https://github.com/conda-incubator/conda-store/issues/new/choose)
+* [conda-store-ui](https://github.com/conda-incubator/conda-store-ui/issues/new/choose)
+* [jupyterlab-conda-store](https://github.com/conda-incubator/jupyterlab-conda-store/issues/new/choose)
+
+If you are unsure about the repository, open your issues against the `conda-store`` repository and the development team will move it to the relevant space.
+
+## Contribute
+
+There are many ways in which you can contribute to conda-store (they're all important, so we list them in alphabetical order):
+
+* [Code maintenance and development →][contribute-code]
+* Community coordination and contributor experience
+* Content translation and internationalization
+* DevOps
+* Fundraising
+* Marketing
+* Project management
+* [Report bugs and submit feature requests →][issues]
+* [Review pull requests →][reviewer-guidelines]
+* [Triage issues and pull requests →][triage]
+* Website design and development
+* [Writing technical documentation →][contribute-docs]
+* UI/UX
+
+<!-- TODO: Add links to contribution guidelines for code, docs, and maintenance. -->
+
+<!-- ## Design assets -->
+
+## Acknowledgements
+
+conda-store's community documentation is inspired by the [Nebari community documentation](https://www.nebari.dev/docs/community).
+
+
+<!-- Internal links -->
+
+[contribute-code]: /community/contribute/contribute-code
+[contribute-docs]: /community/contribute/contribute-docs
+[triage]: /community/maintenance/triage
+[issues]: /community/contribute/issues
+[reviewer-guidelines]: /community/maintenance/reviewer-guidelines
+[conda-store-docs]: /conda-store/introduction
+[conda-store-ui-docs]: /conda-store-ui/introduction
+[jupyterlab-conda-store-docs]: /jupyterlab-conda-store/introduction

docusaurus-docs/community/maintenance/github-conventions.md

@@ -0,0 +1,141 @@
+---
+description: GitHub conventions for the conda-store issue and pull request trackers
+---
+
+# GitHub conventions
+
+This page describes some common conventions and guidelines that we follow in all the conda-store GitHub repositories.
+
+## GitHub labels for issues and pull requests
+
+There are a few GitHub labels that we use to provide key metadata in our issues and pull requests.
+These are added to all conda-store repositories, and share the same meaning across each of them.
+
+Issues and pull requests are classified by having a [`type`](#issue-type) label and a number of optional labels such as [`area`](#area-tag) or [`impact`](#issue-impact).
+
+:::note
+Repositories may define their own labels in addition to the ones described here
+to better reflect the areas and scope of the project.
+:::
+
+### Issue type
+
+**REQUIRED :pushpin:**
+
+**Issue type** determines the kind of issue and implies what sorts of actions must be taken to close it.
+**All issues must be assigned a type label as soon as possible.**
+Issue types are mutually-exclusive - **there may only be one issue type per issue**.
+
+There are a few issue types that are defined for all repositories, for example:
+
+- `type: enhancement 💅🏼`: an incremental improvement to something
+- `type: bug 🐛`: a problem that needs to be fixed
+- `type: maintenance 🛠`: regular maintenance and upkeep
+- `type: discussion 💬`: discussion of general questions, ideas and so on
+
+In addition, other repositories may use repository-specific types, with the caveat that **all issues must still only have one `type` label**.
+
+### Issue impact
+
+**OPTIONAL**
+
+Issue impact is used to signal how much of an impact resolving an issue will have.
+The meaning of this depends on the issue type (for example, enhancement, bug).
+
+The impact should be proportional to a combination of:
+
+- The number of users that will be impacted by an issue's resolution,
+- The extent of the impact our users will feel (for example a major change in experience versus minor improvement)
+- The importance of communities or stakeholders that are impacted by the issue.
+
+These are the impact labels for our issues:
+
+- `impact: high 🟥`
+- `impact: medium 🟨`
+- `impact: low 🟩`
+
+#### Categorizing impact
+
+Here are a few guidelines for how to categorize impact across a few major types of issues.
+
+**Features / Enhancements**
+
+- `impact: high`: Will be seen and commonly used by nearly all users. Has been requested by an abnormally large number of users.
+  Is of particular importance to a key community.
+- `impact: med`: Useful to many users but not an overwhelming amount. Will be a less-obvious improvement.
+  Most issues should be in this category.
+- `impact: low`: Useful but not a critical part of workflows. Is a niche use-case that only a few users may need.
+
+**Bugs**
+
+- `impact: high`: Disruptive to nearly all users, or critically disruptive to many users or key communities
+  (for example, instances won't work at all).
+- `impact: med`: Disruptive to some users, but not in a critical way. Only noticeable under circumstances that aren't very common.
+  Most issues should be in this category.
+- `impact: low`: Minimally disruptive or cosmetic, or only affects a few users or niche use-cases.
+  Note that `accessibility` related issues should be `impact: high` as these are never purely cosmetic changes.
+
+### Area tag
+
+**OPTIONAL**
+
+Tag labels provide hints about what topics that issue is relevant to.
+They are highly repository-specific, optional, and non-exclusive (so issues may have many tags associated with them).
+
+Here are some example tags:
+
+- `area: documentation 📖`: related to documentation in a repository
+- `area: CI 👷🏽‍♀️`: related to continuous integration/deployment
+- `area: design 🎨`: related to design items including UX/UI and graphic design
+
+### Needs labels
+
+**OPTIONAL**
+
+These labels are used to denote what sort of action is needed to resolve an issue or move a pull request forward.
+
+- `needs: discussion 💬`: this issue needs to be discussed in a meeting or in a GitHub issue
+- `needs: follow-up 📫`: someone in the team needs to follow up on this issue or with another stakeholder
+- `needs: review 👀`: this issue needs to be reviewed by a team member
+- `needs: triage 🚦`: this issue needs to be triaged by a team member
+- `needs: investigation 🔍`: this issue needs to be investigated by a team member, often used when an issue was submitted without enough information or reproduction steps
+- `needs: changes 🧱`: this pull request has been reviewed and changes have been requested
+- `needs: tests ✅`: tests need to be added or updated to close this pull request
+- `needs: documentation 📖`: documentation needs to be added or updated to close this pull request
+- `needs: PR 📬`: this issue needs to be worked on, usually as a pull request
+
+### Other labels
+
+A few labels exist to denote particular situations:
+
+- `Close?`: to denote an issue that might need closing, either because the discussion has dried out or there are no concrete follow-up actions
+- `DO-NOT-MERGE`: to denote a PR that should not be merged yet
+- `good first issue`: these issues represents self-contained work that would make a good introduction to project development for a new contributor
+- `Roadmap 🚀`: this issue is part of the project roadmap
+
+## Pull requests
+
+Pull requests are usually associated with or linked to issues. The natural path is to start with an issue and move onto a pull request for resolution.
+But sometimes a new pull request is created without an associated issue.
+In such cases a new issue should be created for that pull request to engage people in a general discussion, not the technical review which is performed in the pull request itself.
+
+If the PR does not need a discussion (trivial fixes, tasks, and so on), the opening of an associated issue may be skipped, but the pull request must be labeled accordingly.
+
+We use mutually exclusive GitHub labels with the prefix`status:` to classify PR's.
+
+- `status: abandoned 🗑`: this pull request has not seen activity in a while (at least a month)
+- `status: stale 🥖`: a "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project.
+- `status: in progress 🏗`: this PR is currently being worked on
+- `status: in review 👀`: this PR is currently being reviewed by the team
+- `status: declined 🙅🏻‍♀️`: this PR has been reviewed and declined for merged
+- `status: approved 💪🏾`: this PR has been reviewed and approved for merge
+- `status: blocked ⛔️`: this PR is blocked by another PR or issue
+
+GitHub notifies team member when labels are changed, so it is useful to keep the status of each pull request as close as possible with the reality.
+For example, if you realize that your PR needs more work after a first pass review, then change the label to `status: in progress 🏗`.
+
+**All PR's must be tagged with a status at all times**
+
+## Issue and PR templates
+
+We use Issue and PR Templates to provide helpful prompts for common issues across all of our repositories.

docusaurus-docs/community/maintenance/index.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 3
+description: Guidelines and resources for conda-store maintenance efforts
+---
+
+# Maintenance guidelines
+
+import DocCardList from '@theme/DocCardList';
+import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
+
+<DocCardList items={useCurrentSidebarCategory().items}/>