From 8e21193668317f57c3979e4f82329660d2a26e34 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 10:02:39 -0400 Subject: [PATCH 01/25] copy napari core dev guide --- CORE_DEV_GUIDE.md | 199 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 CORE_DEV_GUIDE.md diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md new file mode 100644 index 00000000000..ba083ec3973 --- /dev/null +++ b/CORE_DEV_GUIDE.md @@ -0,0 +1,199 @@ +(core-dev-guide)= +# Core Developer guide + +Welcome, new core developer! The core team appreciate the quality of +your work, and enjoy working with you; we have therefore invited you +to join us. Thank you for your numerous contributions to the project +so far. + +You can see a list of all the current core developers on our +[@napari/core-devs](https://github.com/orgs/napari/teams/core-devs) +GitHub team. You should now be on that list too. + +This document offers guidelines for your new role. First and +foremost, you should familiarize yourself with the project's +[mission and values](mission-and-values). When in +doubt, always refer back there. + +As a core team member, you gain the responsibility of shepherding +other contributors through the review process; here are some +guidelines for how to do that. + +## All contributors are treated the same + +As a core developer, you gain the ability to merge or approve +other contributors' pull requests. Much like nuclear launch keys, it +is a shared power: you must merge *only after* another core has +approved the pull request, *and* after you yourself have carefully +reviewed it. (See [Reviewing](#reviewing) and especially +[Merge Only Changes You Understand](#merge-only-changes-you-understand) below.) +It should also be considered best practice to leave a reasonable (24hr) time window +after approval before merge to ensure that other core developers have a reasonable +chance to weigh in. + +We are also an international community, with contributors from many different time zones, +some of whom will only contribute during their working hours, others who might only be able +to contribute during nights and weekends. It is important to be respectful of other peoples +schedules and working habits, even if it slows the project down slightly - we are in this +for the long run. In the same vein you also shouldn't feel pressured to be constantly +available or online, and users or contributors who are overly demanding and unreasonable +to the point of harassment will be directed to our [Code of Conduct](napari-coc). +We value sustainable development practices over mad rushes. + +When merging, use GitHub's +[Squash and Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request) +to ensure a clean git history. + +You should also continue to make your own pull requests as before and in accordance +with the [general contributor guide](napari-contributing). These pull requests still +require the approval of another core developer before they can be merged. + +## Reviewing + +### How to conduct a good review + +*Always* be kind to contributors. Contributors are often doing +volunteer work, for which we are tremendously grateful. Provide +constructive criticism on ideas and implementations, and remind +yourself of how it felt when your own work was being evaluated as a +novice. + +`napari` strongly values mentorship in code review. New users +often need more handholding, having little to no git +experience. Repeat yourself liberally, and, if you don’t recognize a +contributor, point them to our development guide, or other GitHub +workflow tutorials around the web. Do not assume that they know how +GitHub works (many don't realize that adding a commit +automatically updates a pull request, for example). Gentle, polite, kind +encouragement can make the difference between a new core developer and +an abandoned pull request. + +When reviewing, focus on the following: + +1. **Usability and generality:** `napari` is a GUI application that strives to be accessible +to both coding and non-coding users, and new features should ultimately be +accessible to everyone using the app. `napari` targets the scientific user +community broadly, and core features should be domain-agnostic and general purpose. +Custom functionality is meant to be provided through our plugin ecosystem. If in doubt, +consult back with our [mission and values](mission-and-values). + +2. **Performance and benchmarks:** As `napari` targets scientific applications that often involve +large multidimensional datasets, high performance is a key value of `napari`. While +every new feature won't scale equally to all sizes of data, keeping in mind performance +and our [benchmarks](napari-benchmarks) during a review may be important, and you may +need to ask for benchmarks to be run and reported or new benchmarks to be added. + +3. **APIs and stability:** Coding users and plugin developers will make +extensive use of our APIs. The foundation of a healthy plugin ecosystem will be +a fully capable and stable set of APIs, so as `napari` matures it will +very important to ensure our APIs are stable. For now, while the project is still +in an earlier stage, spending the extra time to consider names of public facing +variables and methods, along side function signatures, could save us considerable +trouble in the future. Right now we are still making breaking changes with minor +version numbers `0.x` and do not have a deprecation policy, but we will work to add one soon. + +4. **Documentation and tutorials:** All new methods should have appropriate doc +strings following [PEP257](https://peps.python.org/pep-0257/) and the +[NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style). +For any major new features, accompanying changes should be made to our +[tutorials](https://napari.org/tutorials). These should not only +illustrates the new feature, but explains it. Titles for all documents in napari should follow [sentence case capitalization](https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case), but the name `napari` should always be written in lowercase. + +5. **Implementations and algorithms:** You should understand the code being modified +or added before approving it. (See [Merge Only Changes You Understand](#merge-only-changes-you-understand) +below.) Implementations should do what they claim and be simple, readable, and efficient +in that order. + +6. **Tests:** All contributions *must* be tested, and each added line of code +should be covered by at least one test. Good tests not only execute the code, +but explore corner cases. It can be tempting not to review tests, but please +do so. + +Other changes may be *nitpicky*: spelling mistakes, formatting, +etc. Do not insist contributors make these changes, but instead you should offer +to make these changes by [pushing to their branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork), or using GitHub’s [suggestion](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request) +[feature](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request), and +be prepared to make them yourself if needed. Using the suggestion feature is preferred because +it gives the contributor a choice in whether to accept the changes. + +Unless you know that a contributor is experienced with git, don’t +ask for a rebase when merge conflicts arise. Instead, rebase the +branch yourself, force-push to their branch, and advise the contributor to force-pull. If the contributor is +no longer active, you may take over their branch by submitting a new pull +request and closing the original, including a reference to the original pull +request. In doing so, ensure you communicate that you are not throwing the +contributor's work away! + +### Merge only changes you understand + +*Long-term maintainability* is an important concern. Code doesn't +merely have to *work*, but should be *understood* by multiple core +developers. Changes will have to be made in the future, and the +original contributor may have moved on. + +Therefore, *do not merge a code change unless you understand it*. Ask +for help freely: we can consult community members, or even external developers, +for added insight where needed, and see this as a great learning opportunity. + +While we collectively "own" any patches (and bugs!) that become part +of the code base, you are vouching for changes you merge. Please take +that responsibility seriously. + +## Further resources + +As a core member, you should be familiar with community and developer +resources such as: + +- Our [contributor guide](napari-contributing). +- Our [code of conduct](napari-coc). +- Our [governance](napari-governance). +- Our [mission and values](mission-and-values). +- Our [benchmarking guide](napari-benchmarks). +- [PEP8](https://peps.python.org/pep-0008/) for Python style. +- [PEP257](https://peps.python.org/pep-0257/) and the + [NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style) + for docstring conventions. +- [`pre-commit`](https://pre-commit.com) hooks for autoformatting. +- [`black`](https://github.com/psf/black) autoformatting. +- [`flake8`](https://github.com/PyCQA/flake8) linting. +- [#napari on image.sc](https://forum.image.sc/tag/napari). +- [#napari](https://twitter.com/search?q=%23napari&f=live) and [@napari_imaging](https://twitter.com/napari_imaging) on twitter. +- [napari zulip](https://napari.zulipchat.com/) community chat channel. + +You are not required to monitor the social resources. + +Where possible we prefer to point people towards asynchronous forms of communication +like forum posts and github issues instead of realtime chat options as they are easier +for a global community to consume. + +We also have a private mailing list for core developers +`napari-core-devs@googlegroups.com` which is sparingly used for discussions +that are required to be private, such as voting on new core members. + +## Inviting new core members + +Any core member may nominate other contributors to join the core team. +While there is no hard-and-fast rule about who can be nominated, ideally, +they should have: been part of the project for at least two months, contributed +significant changes of their own, contributed to the discussion and +review of others' work, and collaborated in a way befitting our +community values. After nomination voting will happen on a private mailing list. +While it is expected that most votes will be unanimous, a two-thirds majority of +the cast votes is enough. + +Core developers can choose to become emeritus core developers and suspend +their approval and voting rights until they become active again. + +## Contribute to this guide (!) + +This guide reflects the experience of the current core developers. We +may well have missed things that, by now, have become second +nature—things that you, as a new team member, will spot more easily. +Please ask the other core developers if you have any questions, and +submit a pull request with insights gained. + +## Conclusion + +We are excited to have you on board! We look forward to your +contributions to the code base and the community. Thank you in +advance! From cd7f417686f0ef710c6c5cfe23b807675c0003c9 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 10:03:16 -0400 Subject: [PATCH 02/25] replace all instance of napari with xarray --- CORE_DEV_GUIDE.md | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index ba083ec3973..f0bd8262f49 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -7,7 +7,7 @@ to join us. Thank you for your numerous contributions to the project so far. You can see a list of all the current core developers on our -[@napari/core-devs](https://github.com/orgs/napari/teams/core-devs) +[@xarray/core-devs](https://github.com/orgs/xarray/teams/core-devs) GitHub team. You should now be on that list too. This document offers guidelines for your new role. First and @@ -37,7 +37,7 @@ to contribute during nights and weekends. It is important to be respectful of ot schedules and working habits, even if it slows the project down slightly - we are in this for the long run. In the same vein you also shouldn't feel pressured to be constantly available or online, and users or contributors who are overly demanding and unreasonable -to the point of harassment will be directed to our [Code of Conduct](napari-coc). +to the point of harassment will be directed to our [Code of Conduct](xarray-coc). We value sustainable development practices over mad rushes. When merging, use GitHub's @@ -45,7 +45,7 @@ When merging, use GitHub's to ensure a clean git history. You should also continue to make your own pull requests as before and in accordance -with the [general contributor guide](napari-contributing). These pull requests still +with the [general contributor guide](xarray-contributing). These pull requests still require the approval of another core developer before they can be merged. ## Reviewing @@ -58,7 +58,7 @@ constructive criticism on ideas and implementations, and remind yourself of how it felt when your own work was being evaluated as a novice. -`napari` strongly values mentorship in code review. New users +`xarray` strongly values mentorship in code review. New users often need more handholding, having little to no git experience. Repeat yourself liberally, and, if you don’t recognize a contributor, point them to our development guide, or other GitHub @@ -70,22 +70,22 @@ an abandoned pull request. When reviewing, focus on the following: -1. **Usability and generality:** `napari` is a GUI application that strives to be accessible +1. **Usability and generality:** `xarray` is a GUI application that strives to be accessible to both coding and non-coding users, and new features should ultimately be -accessible to everyone using the app. `napari` targets the scientific user +accessible to everyone using the app. `xarray` targets the scientific user community broadly, and core features should be domain-agnostic and general purpose. Custom functionality is meant to be provided through our plugin ecosystem. If in doubt, consult back with our [mission and values](mission-and-values). -2. **Performance and benchmarks:** As `napari` targets scientific applications that often involve -large multidimensional datasets, high performance is a key value of `napari`. While +2. **Performance and benchmarks:** As `xarray` targets scientific applications that often involve +large multidimensional datasets, high performance is a key value of `xarray`. While every new feature won't scale equally to all sizes of data, keeping in mind performance -and our [benchmarks](napari-benchmarks) during a review may be important, and you may +and our [benchmarks](xarray-benchmarks) during a review may be important, and you may need to ask for benchmarks to be run and reported or new benchmarks to be added. 3. **APIs and stability:** Coding users and plugin developers will make extensive use of our APIs. The foundation of a healthy plugin ecosystem will be -a fully capable and stable set of APIs, so as `napari` matures it will +a fully capable and stable set of APIs, so as `xarray` matures it will very important to ensure our APIs are stable. For now, while the project is still in an earlier stage, spending the extra time to consider names of public facing variables and methods, along side function signatures, could save us considerable @@ -96,8 +96,8 @@ version numbers `0.x` and do not have a deprecation policy, but we will work to strings following [PEP257](https://peps.python.org/pep-0257/) and the [NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style). For any major new features, accompanying changes should be made to our -[tutorials](https://napari.org/tutorials). These should not only -illustrates the new feature, but explains it. Titles for all documents in napari should follow [sentence case capitalization](https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case), but the name `napari` should always be written in lowercase. +[tutorials](https://xarray.org/tutorials). These should not only +illustrates the new feature, but explains it. Titles for all documents in xarray should follow [sentence case capitalization](https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case), but the name `xarray` should always be written in lowercase. 5. **Implementations and algorithms:** You should understand the code being modified or added before approving it. (See [Merge Only Changes You Understand](#merge-only-changes-you-understand) @@ -144,11 +144,11 @@ that responsibility seriously. As a core member, you should be familiar with community and developer resources such as: -- Our [contributor guide](napari-contributing). -- Our [code of conduct](napari-coc). -- Our [governance](napari-governance). +- Our [contributor guide](xarray-contributing). +- Our [code of conduct](xarray-coc). +- Our [governance](xarray-governance). - Our [mission and values](mission-and-values). -- Our [benchmarking guide](napari-benchmarks). +- Our [benchmarking guide](xarray-benchmarks). - [PEP8](https://peps.python.org/pep-0008/) for Python style. - [PEP257](https://peps.python.org/pep-0257/) and the [NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style) @@ -156,9 +156,9 @@ resources such as: - [`pre-commit`](https://pre-commit.com) hooks for autoformatting. - [`black`](https://github.com/psf/black) autoformatting. - [`flake8`](https://github.com/PyCQA/flake8) linting. -- [#napari on image.sc](https://forum.image.sc/tag/napari). -- [#napari](https://twitter.com/search?q=%23napari&f=live) and [@napari_imaging](https://twitter.com/napari_imaging) on twitter. -- [napari zulip](https://napari.zulipchat.com/) community chat channel. +- [#xarray on image.sc](https://forum.image.sc/tag/xarray). +- [#xarray](https://twitter.com/search?q=%23xarray&f=live) and [@xarray_imaging](https://twitter.com/xarray_imaging) on twitter. +- [xarray zulip](https://xarray.zulipchat.com/) community chat channel. You are not required to monitor the social resources. @@ -167,7 +167,7 @@ like forum posts and github issues instead of realtime chat options as they are for a global community to consume. We also have a private mailing list for core developers -`napari-core-devs@googlegroups.com` which is sparingly used for discussions +`xarray-core-devs@googlegroups.com` which is sparingly used for discussions that are required to be private, such as voting on new core members. ## Inviting new core members From ab838184fed62c22c100c3de344d5aec34b577ed Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 10:41:41 -0400 Subject: [PATCH 03/25] rewrite some napari-specific sentences --- CORE_DEV_GUIDE.md | 46 +++++++++++++++++++++------------------------- 1 file changed, 21 insertions(+), 25 deletions(-) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index f0bd8262f49..46a544c4a67 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -1,3 +1,5 @@ +> **_NOTE:_** This Core Developer Guide was adapted from the [Napari Project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). + (core-dev-guide)= # Core Developer guide @@ -7,13 +9,9 @@ to join us. Thank you for your numerous contributions to the project so far. You can see a list of all the current core developers on our -[@xarray/core-devs](https://github.com/orgs/xarray/teams/core-devs) +[@pydata/xarray](https://github.com/orgs/pydata/teams/xarray) GitHub team. You should now be on that list too. - -This document offers guidelines for your new role. First and -foremost, you should familiarize yourself with the project's -[mission and values](mission-and-values). When in -doubt, always refer back there. +This document offers guidelines for your new role. As a core team member, you gain the responsibility of shepherding other contributors through the review process; here are some @@ -37,15 +35,15 @@ to contribute during nights and weekends. It is important to be respectful of ot schedules and working habits, even if it slows the project down slightly - we are in this for the long run. In the same vein you also shouldn't feel pressured to be constantly available or online, and users or contributors who are overly demanding and unreasonable -to the point of harassment will be directed to our [Code of Conduct](xarray-coc). +to the point of harassment will be directed to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). We value sustainable development practices over mad rushes. -When merging, use GitHub's +When merging, we automatically use GitHub's [Squash and Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request) to ensure a clean git history. You should also continue to make your own pull requests as before and in accordance -with the [general contributor guide](xarray-contributing). These pull requests still +with the [general contributing guide](https://docs.xarray.dev/en/stable/contributing.html). These pull requests still require the approval of another core developer before they can be merged. ## Reviewing @@ -70,34 +68,32 @@ an abandoned pull request. When reviewing, focus on the following: -1. **Usability and generality:** `xarray` is a GUI application that strives to be accessible -to both coding and non-coding users, and new features should ultimately be -accessible to everyone using the app. `xarray` targets the scientific user +1. **Usability and generality:** `xarray` is a user-facing package that strives to be accessible +to both novice and advanced users, and new features should ultimately be +accessible to everyone using the package. `xarray` targets the scientific user community broadly, and core features should be domain-agnostic and general purpose. -Custom functionality is meant to be provided through our plugin ecosystem. If in doubt, -consult back with our [mission and values](mission-and-values). +Custom functionality is meant to be provided through our various types of interoperability. 2. **Performance and benchmarks:** As `xarray` targets scientific applications that often involve large multidimensional datasets, high performance is a key value of `xarray`. While every new feature won't scale equally to all sizes of data, keeping in mind performance -and our [benchmarks](xarray-benchmarks) during a review may be important, and you may +and our [benchmarks](https://github.com/pydata/xarray/tree/main/asv_bench) during a review may be important, and you may need to ask for benchmarks to be run and reported or new benchmarks to be added. -3. **APIs and stability:** Coding users and plugin developers will make -extensive use of our APIs. The foundation of a healthy plugin ecosystem will be +3. **APIs and stability:** Coding users and developers will make +extensive use of our APIs. The foundation of a healthy ecosystem will be a fully capable and stable set of APIs, so as `xarray` matures it will -very important to ensure our APIs are stable. For now, while the project is still -in an earlier stage, spending the extra time to consider names of public facing -variables and methods, along side function signatures, could save us considerable -trouble in the future. Right now we are still making breaking changes with minor -version numbers `0.x` and do not have a deprecation policy, but we will work to add one soon. +very important to ensure our APIs are stable. Spending the extra time to consider names of public facing +variables and methods, alongside function signatures, could save us considerable +trouble in the future. We do our best to provide [deprecation cycles](https://docs.xarray.dev/en/stable/contributing.html#backwards-compatibility) +when making backwards-incompatible changes. 4. **Documentation and tutorials:** All new methods should have appropriate doc strings following [PEP257](https://peps.python.org/pep-0257/) and the [NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style). For any major new features, accompanying changes should be made to our -[tutorials](https://xarray.org/tutorials). These should not only -illustrates the new feature, but explains it. Titles for all documents in xarray should follow [sentence case capitalization](https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case), but the name `xarray` should always be written in lowercase. +[tutorials](https://tutorial.xarray.dev). These should not only +illustrates the new feature, but explains it. 5. **Implementations and algorithms:** You should understand the code being modified or added before approving it. (See [Merge Only Changes You Understand](#merge-only-changes-you-understand) @@ -167,7 +163,7 @@ like forum posts and github issues instead of realtime chat options as they are for a global community to consume. We also have a private mailing list for core developers -`xarray-core-devs@googlegroups.com` which is sparingly used for discussions +`xarray-core-team@googlegroups.com` which is sparingly used for discussions that are required to be private, such as voting on new core members. ## Inviting new core members From 818f9586c4eb06d807e1f0f70c01cedba5f258b8 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 10:54:12 -0400 Subject: [PATCH 04/25] update links in the resources --- CORE_DEV_GUIDE.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index 46a544c4a67..87fa33ada46 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -140,11 +140,9 @@ that responsibility seriously. As a core member, you should be familiar with community and developer resources such as: -- Our [contributor guide](xarray-contributing). -- Our [code of conduct](xarray-coc). -- Our [governance](xarray-governance). -- Our [mission and values](mission-and-values). -- Our [benchmarking guide](xarray-benchmarks). +- Our [contributor guide](https://docs.xarray.dev/en/stable/contributing.html). +- Our [code of conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). +- Our [philosophy and development roadmap](https://docs.xarray.dev/en/stable/roadmap.html). - [PEP8](https://peps.python.org/pep-0008/) for Python style. - [PEP257](https://peps.python.org/pep-0257/) and the [NumPy documentation guide](https://numpy.org/devdocs/dev/howto-docs.html#documentation-style) @@ -152,15 +150,15 @@ resources such as: - [`pre-commit`](https://pre-commit.com) hooks for autoformatting. - [`black`](https://github.com/psf/black) autoformatting. - [`flake8`](https://github.com/PyCQA/flake8) linting. -- [#xarray on image.sc](https://forum.image.sc/tag/xarray). -- [#xarray](https://twitter.com/search?q=%23xarray&f=live) and [@xarray_imaging](https://twitter.com/xarray_imaging) on twitter. -- [xarray zulip](https://xarray.zulipchat.com/) community chat channel. +- [python-xarray](https://stackoverflow.com/questions/tagged/python-xarray) on Stack Overflow. +- [@xarray_dev](https://twitter.com/xarray_dev) on Twitter. +- [xarray-dev](https://discord.gg/bsSGdwBn) discord community (normally only used for remote synchronous chat during sprints). -You are not required to monitor the social resources. +You are not required to monitor any of the social resources. Where possible we prefer to point people towards asynchronous forms of communication -like forum posts and github issues instead of realtime chat options as they are easier -for a global community to consume. +like github issues instead of realtime chat options as they are far easier +for a global community to consume and refer back to. We also have a private mailing list for core developers `xarray-core-team@googlegroups.com` which is sparingly used for discussions From 868959286e15133ab22f548da92f58775723be36 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 11:09:14 -0400 Subject: [PATCH 05/25] list tasks --- CORE_DEV_GUIDE.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index 87fa33ada46..17c308eacd6 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -46,6 +46,31 @@ You should also continue to make your own pull requests as before and in accorda with the [general contributing guide](https://docs.xarray.dev/en/stable/contributing.html). These pull requests still require the approval of another core developer before they can be merged. +## Tasks + +Xarray values a wide range of contributions, only some of which involve writing code. +As such, we do not currently make a distinction between a "core developer", "maintainer", +or "triage team member" as some projects (e.g. [pandas](https://pandas.pydata.org/docs/development/maintaining.html)) do. + +Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “expectations”. +**There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). +Rather, the tasks that follow are general descriptions of what it might mean to be a core dev/maintainer. + +- Triage newly filed issues (see Issue triage), +- Review newly opened pull requests, +- Respond to updates on existing issues and pull requests, +- Drive discussion and decisions on stalled issues and pull requests, +- Provide experience / wisdom on API design questions to ensure consistency and maintainability, +- Project organization (run / attend developer meetings, represent xarray), +- Project evangelism (advertise xarray to new users / collaborate with maintainers of packages which could interoperate with xarray), +- Project fundraising (help write and administrate grants that will support xarray), +- Improve documentation or tutorials, +- Maintain xarray's various Continuous Integration Workflows, +- Write code that goes into xarray `main`. + +Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be interesting background reading, +but should not be taken to strictly apply to the Xarray project. + ## Reviewing ### How to conduct a good review From 6ec673d7e51e4c9494ce4b5df1f9bcce70855acb Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 11:21:33 -0400 Subject: [PATCH 06/25] fixes --- CORE_DEV_GUIDE.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index 17c308eacd6..8191ddcdf8c 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -1,6 +1,5 @@ -> **_NOTE:_** This Core Developer Guide was adapted from the [Napari Project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). +> **_Note:_** This Core Developer Guide was adapted from the [napari project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). -(core-dev-guide)= # Core Developer guide Welcome, new core developer! The core team appreciate the quality of @@ -50,19 +49,19 @@ require the approval of another core developer before they can be merged. Xarray values a wide range of contributions, only some of which involve writing code. As such, we do not currently make a distinction between a "core developer", "maintainer", -or "triage team member" as some projects (e.g. [pandas](https://pandas.pydata.org/docs/development/maintaining.html)) do. +or "triage team member" as some projects do (e.g. [pandas](https://pandas.pydata.org/docs/development/maintaining.html)). Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “expectations”. **There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). Rather, the tasks that follow are general descriptions of what it might mean to be a core dev/maintainer. -- Triage newly filed issues (see Issue triage), +- Triage newly filed issues, - Review newly opened pull requests, - Respond to updates on existing issues and pull requests, - Drive discussion and decisions on stalled issues and pull requests, - Provide experience / wisdom on API design questions to ensure consistency and maintainability, - Project organization (run / attend developer meetings, represent xarray), -- Project evangelism (advertise xarray to new users / collaborate with maintainers of packages which could interoperate with xarray), +- Project evangelism (advertise xarray to new users / collaborate with maintainers of other packages which could interface with xarray), - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials, - Maintain xarray's various Continuous Integration Workflows, @@ -71,6 +70,15 @@ Rather, the tasks that follow are general descriptions of what it might mean to Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be interesting background reading, but should not be taken to strictly apply to the Xarray project. +It is natural that your available time and enthusiasm for the project will wax and wane - this is fine and expected! +It is also common for core developers to have a "niche" - a particular part of the codebase they have specific expertise +with, or certain type of task above which they primarily perform. + +If however you feel that is unlikely you will be able to be actively contribute in the foreseeable future +(or especially if you won't be available to answer questions about pieces of code that you wrote previously) +then you may want to consider letting us know you would rather be listed as an "Emeritus Core Developer", +as this would help us in evaluating the overall health of the project. + ## Reviewing ### How to conduct a good review From 8608956c917eb89d3f7ad44f3a9a8e5d186e8fae Mon Sep 17 00:00:00 2001 From: Tom Nicholas Date: Tue, 18 Jul 2023 12:00:26 -0400 Subject: [PATCH 07/25] mention the plan to merge label Co-authored-by: Michael Niklas --- CORE_DEV_GUIDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CORE_DEV_GUIDE.md b/CORE_DEV_GUIDE.md index 8191ddcdf8c..4a4ba6cd586 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_DEV_GUIDE.md @@ -27,6 +27,7 @@ reviewed it. (See [Reviewing](#reviewing) and especially It should also be considered best practice to leave a reasonable (24hr) time window after approval before merge to ensure that other core developers have a reasonable chance to weigh in. +Adding the "plan to merge" label notifies developers of the imminent merge. We are also an international community, with contributors from many different time zones, some of whom will only contribute during their working hours, others who might only be able From 78b9e1a5a2fc334846ea3600f0e1ad0e205559fb Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:09:20 -0400 Subject: [PATCH 08/25] core dev -> core team member --- CORE_DEV_GUIDE.md => CORE_TEAM_GUIDE.md | 34 ++++++++++++------------- 1 file changed, 17 insertions(+), 17 deletions(-) rename CORE_DEV_GUIDE.md => CORE_TEAM_GUIDE.md (90%) diff --git a/CORE_DEV_GUIDE.md b/CORE_TEAM_GUIDE.md similarity index 90% rename from CORE_DEV_GUIDE.md rename to CORE_TEAM_GUIDE.md index 4a4ba6cd586..0a040373990 100644 --- a/CORE_DEV_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -1,13 +1,13 @@ -> **_Note:_** This Core Developer Guide was adapted from the [napari project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). +> **_Note:_** This Core Team Member Guide was adapted from the [napari project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). -# Core Developer guide +# Core Team Member Guide -Welcome, new core developer! The core team appreciate the quality of +Welcome, new core team member! The core team appreciate the quality of your work, and enjoy working with you; we have therefore invited you to join us. Thank you for your numerous contributions to the project so far. -You can see a list of all the current core developers on our +You can see a list of all the current core team members on our [@pydata/xarray](https://github.com/orgs/pydata/teams/xarray) GitHub team. You should now be on that list too. This document offers guidelines for your new role. @@ -18,14 +18,14 @@ guidelines for how to do that. ## All contributors are treated the same -As a core developer, you gain the ability to merge or approve +As a core team member, you gain the ability to merge or approve other contributors' pull requests. Much like nuclear launch keys, it is a shared power: you must merge *only after* another core has approved the pull request, *and* after you yourself have carefully reviewed it. (See [Reviewing](#reviewing) and especially [Merge Only Changes You Understand](#merge-only-changes-you-understand) below.) It should also be considered best practice to leave a reasonable (24hr) time window -after approval before merge to ensure that other core developers have a reasonable +after approval before merge to ensure that other core team members have a reasonable chance to weigh in. Adding the "plan to merge" label notifies developers of the imminent merge. @@ -44,17 +44,17 @@ to ensure a clean git history. You should also continue to make your own pull requests as before and in accordance with the [general contributing guide](https://docs.xarray.dev/en/stable/contributing.html). These pull requests still -require the approval of another core developer before they can be merged. +require the approval of another core team member before they can be merged. ## Tasks Xarray values a wide range of contributions, only some of which involve writing code. -As such, we do not currently make a distinction between a "core developer", "maintainer", +As such, we do not currently make a distinction between a "core team member", "core developer", "maintainer", or "triage team member" as some projects do (e.g. [pandas](https://pandas.pydata.org/docs/development/maintaining.html)). Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “expectations”. **There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). -Rather, the tasks that follow are general descriptions of what it might mean to be a core dev/maintainer. +Rather, the tasks that follow are general descriptions of what it might mean to be a core team member: - Triage newly filed issues, - Review newly opened pull requests, @@ -72,12 +72,12 @@ Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blo but should not be taken to strictly apply to the Xarray project. It is natural that your available time and enthusiasm for the project will wax and wane - this is fine and expected! -It is also common for core developers to have a "niche" - a particular part of the codebase they have specific expertise -with, or certain type of task above which they primarily perform. +It is also common for core team members to have a "niche" - a particular part of the codebase they have specific expertise +with, or certain types of task above which they primarily perform. If however you feel that is unlikely you will be able to be actively contribute in the foreseeable future (or especially if you won't be available to answer questions about pieces of code that you wrote previously) -then you may want to consider letting us know you would rather be listed as an "Emeritus Core Developer", +then you may want to consider letting us know you would rather be listed as an "Emeritus Core Team Member", as this would help us in evaluating the overall health of the project. ## Reviewing @@ -97,7 +97,7 @@ contributor, point them to our development guide, or other GitHub workflow tutorials around the web. Do not assume that they know how GitHub works (many don't realize that adding a commit automatically updates a pull request, for example). Gentle, polite, kind -encouragement can make the difference between a new core developer and +encouragement can make the difference between a new core team member and an abandoned pull request. When reviewing, focus on the following: @@ -194,7 +194,7 @@ Where possible we prefer to point people towards asynchronous forms of communica like github issues instead of realtime chat options as they are far easier for a global community to consume and refer back to. -We also have a private mailing list for core developers +We also have a private mailing list for core team members `xarray-core-team@googlegroups.com` which is sparingly used for discussions that are required to be private, such as voting on new core members. @@ -209,15 +209,15 @@ community values. After nomination voting will happen on a private mailing list. While it is expected that most votes will be unanimous, a two-thirds majority of the cast votes is enough. -Core developers can choose to become emeritus core developers and suspend +Core team members can choose to become emeritus core team members and suspend their approval and voting rights until they become active again. ## Contribute to this guide (!) -This guide reflects the experience of the current core developers. We +This guide reflects the experience of the current core team members. We may well have missed things that, by now, have become second nature—things that you, as a new team member, will spot more easily. -Please ask the other core developers if you have any questions, and +Please ask the other core team members if you have any questions, and submit a pull request with insights gained. ## Conclusion From 7eb0da6b1787a4045e862f32f2235844f765a763 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:12:11 -0400 Subject: [PATCH 09/25] choose your own title --- CORE_TEAM_GUIDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 0a040373990..0bab9df11d9 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -51,6 +51,7 @@ require the approval of another core team member before they can be merged. Xarray values a wide range of contributions, only some of which involve writing code. As such, we do not currently make a distinction between a "core team member", "core developer", "maintainer", or "triage team member" as some projects do (e.g. [pandas](https://pandas.pydata.org/docs/development/maintaining.html)). +That said, if you prefer to refer to your role as one of the other titles above then that is fine by us! Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “expectations”. **There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). From 3d6a25cac26193e0c224d2160628f9fae04d259b Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:34:51 -0400 Subject: [PATCH 10/25] rearrange sections to put tasks before code contributions --- CORE_TEAM_GUIDE.md | 72 ++++++++++++++++++++++++---------------------- 1 file changed, 37 insertions(+), 35 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 0bab9df11d9..3e32a376d84 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -12,40 +12,6 @@ You can see a list of all the current core team members on our GitHub team. You should now be on that list too. This document offers guidelines for your new role. -As a core team member, you gain the responsibility of shepherding -other contributors through the review process; here are some -guidelines for how to do that. - -## All contributors are treated the same - -As a core team member, you gain the ability to merge or approve -other contributors' pull requests. Much like nuclear launch keys, it -is a shared power: you must merge *only after* another core has -approved the pull request, *and* after you yourself have carefully -reviewed it. (See [Reviewing](#reviewing) and especially -[Merge Only Changes You Understand](#merge-only-changes-you-understand) below.) -It should also be considered best practice to leave a reasonable (24hr) time window -after approval before merge to ensure that other core team members have a reasonable -chance to weigh in. -Adding the "plan to merge" label notifies developers of the imminent merge. - -We are also an international community, with contributors from many different time zones, -some of whom will only contribute during their working hours, others who might only be able -to contribute during nights and weekends. It is important to be respectful of other peoples -schedules and working habits, even if it slows the project down slightly - we are in this -for the long run. In the same vein you also shouldn't feel pressured to be constantly -available or online, and users or contributors who are overly demanding and unreasonable -to the point of harassment will be directed to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). -We value sustainable development practices over mad rushes. - -When merging, we automatically use GitHub's -[Squash and Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request) -to ensure a clean git history. - -You should also continue to make your own pull requests as before and in accordance -with the [general contributing guide](https://docs.xarray.dev/en/stable/contributing.html). These pull requests still -require the approval of another core team member before they can be merged. - ## Tasks Xarray values a wide range of contributions, only some of which involve writing code. @@ -81,7 +47,43 @@ If however you feel that is unlikely you will be able to be actively contribute then you may want to consider letting us know you would rather be listed as an "Emeritus Core Team Member", as this would help us in evaluating the overall health of the project. -## Reviewing +## Code contributions + +As a core team member, you are a representative of the project, +and trusted to make decisions that will serve the long term interests +of all users. You also gain the responsibility of shepherding +other contributors through the review process; here are some +guidelines for how to do that. + +## All contributors are treated the same + +You should now have gained the ability to merge or approve +other contributors' pull requests. Much like nuclear launch keys, it +is a shared power: you must merge *only after* another core has +approved the pull request, *and* after you yourself have carefully +reviewed it. (See [Reviewing](#reviewing) and especially +[Merge Only Changes You Understand](#merge-only-changes-you-understand) below.) +It should also be considered best practice to leave a reasonable (24hr) time window +after approval before merge to ensure that other core team members have a reasonable +chance to weigh in. +Adding the "plan to merge" label notifies developers of the imminent merge. + +We are also an international community, with contributors from many different time zones, +some of whom will only contribute during their working hours, others who might only be able +to contribute during nights and weekends. It is important to be respectful of other peoples +schedules and working habits, even if it slows the project down slightly - we are in this +for the long run. In the same vein you also shouldn't feel pressured to be constantly +available or online, and users or contributors who are overly demanding and unreasonable +to the point of harassment will be directed to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). +We value sustainable development practices over mad rushes. + +When merging, we automatically use GitHub's +[Squash and Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request#merging-a-pull-request) +to ensure a clean git history. + +You should also continue to make your own pull requests as before and in accordance +with the [general contributing guide](https://docs.xarray.dev/en/stable/contributing.html). These pull requests still +require the approval of another core team member before they can be merged. ### How to conduct a good review From bd71ff60fba7db849a7a540dd4a15d27b79e4250 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:37:48 -0400 Subject: [PATCH 11/25] remove dramatic nuclear launch keys analogy --- CORE_TEAM_GUIDE.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 3e32a376d84..d2a9c302c7f 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -58,11 +58,13 @@ guidelines for how to do that. ## All contributors are treated the same You should now have gained the ability to merge or approve -other contributors' pull requests. Much like nuclear launch keys, it -is a shared power: you must merge *only after* another core has -approved the pull request, *and* after you yourself have carefully -reviewed it. (See [Reviewing](#reviewing) and especially +other contributors' pull requests. Merging contributions is a shared power: +only merge contributions you yourself have carefully reviewed, and that are +clear improvements for the project. When in doubt, and especially for more +complex changes, wait until at least one other core team member has approved. +(See [Reviewing](#reviewing) and especially [Merge Only Changes You Understand](#merge-only-changes-you-understand) below.) + It should also be considered best practice to leave a reasonable (24hr) time window after approval before merge to ensure that other core team members have a reasonable chance to weigh in. From 6a15feebf31e6e34ce7345ecb167af238afb4a49 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:50:20 -0400 Subject: [PATCH 12/25] link to bi-weekly developers meeting --- CORE_TEAM_GUIDE.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index d2a9c302c7f..590b5313fcb 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -199,6 +199,11 @@ Where possible we prefer to point people towards asynchronous forms of communica like github issues instead of realtime chat options as they are far easier for a global community to consume and refer back to. +We hold a [bi-weekly developers meeting](https://docs.xarray.dev/en/stable/developers-meeting.html) via video call. +This is a great place to bring up any questions you have, raise visibility of an issue and/or gather more perspectives. +Attendance is absolutely optional, and we keep the meeting to 30 minutes in respect of your valuable time. +This meeting is public, so we occasionally have non-core team members join us. + We also have a private mailing list for core team members `xarray-core-team@googlegroups.com` which is sparingly used for discussions that are required to be private, such as voting on new core members. From a4291f48cf4ec33236281ab5c77760ad67958c09 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 12:56:23 -0400 Subject: [PATCH 13/25] add more types of tasks --- CORE_TEAM_GUIDE.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 590b5313fcb..8a544bd4fe0 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -31,7 +31,9 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Project organization (run / attend developer meetings, represent xarray), - Project evangelism (advertise xarray to new users / collaborate with maintainers of other packages which could interface with xarray), - Project fundraising (help write and administrate grants that will support xarray), -- Improve documentation or tutorials, +- Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), +- Maintain the [`xarray.dev`](https://xarray.dev/) landing page and website, the [code for which is here](https://github.com/xarray-contrib/xarray.dev), +- Write blog posts on the [xarray blog](https://xarray.dev/blog), - Maintain xarray's various Continuous Integration Workflows, - Write code that goes into xarray `main`. From b70c061d6f9617778310e94803f86a77cb16c3dc Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:02:54 -0400 Subject: [PATCH 14/25] mention presenting tutorials --- CORE_TEAM_GUIDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 8a544bd4fe0..312072257e6 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -32,6 +32,7 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Project evangelism (advertise xarray to new users / collaborate with maintainers of other packages which could interface with xarray), - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), +- Presenting or running tutorials (such as those we have given at the SciPy conference), - Maintain the [`xarray.dev`](https://xarray.dev/) landing page and website, the [code for which is here](https://github.com/xarray-contrib/xarray.dev), - Write blog posts on the [xarray blog](https://xarray.dev/blog), - Maintain xarray's various Continuous Integration Workflows, From cdd1de4ceabdc8ea34f7b2cfd4e7f175c2ecca51 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:03:16 -0400 Subject: [PATCH 15/25] mention representing xarray in user communities --- CORE_TEAM_GUIDE.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 312072257e6..24aa46eb161 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -28,8 +28,9 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Respond to updates on existing issues and pull requests, - Drive discussion and decisions on stalled issues and pull requests, - Provide experience / wisdom on API design questions to ensure consistency and maintainability, -- Project organization (run / attend developer meetings, represent xarray), +- Project organization (run / attend developer meetings, coordinate with sponsors), - Project evangelism (advertise xarray to new users / collaborate with maintainers of other packages which could interface with xarray), +- Community contact (represent xarray in user communities such as [Pangeo](https://pangeo.io/)), - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), - Presenting or running tutorials (such as those we have given at the SciPy conference), From 40f0b2e2d0c5df4f2da3218d2b327e2982cdde74 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:06:23 -0400 Subject: [PATCH 16/25] yet more tasks --- CORE_TEAM_GUIDE.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 24aa46eb161..49360a791b7 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -29,8 +29,9 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Drive discussion and decisions on stalled issues and pull requests, - Provide experience / wisdom on API design questions to ensure consistency and maintainability, - Project organization (run / attend developer meetings, coordinate with sponsors), -- Project evangelism (advertise xarray to new users / collaborate with maintainers of other packages which could interface with xarray), +- Project evangelism (advertise xarray to new users), - Community contact (represent xarray in user communities such as [Pangeo](https://pangeo.io/)), +- Key project contact (represent xarray's perspective within key related projects like numpy, Zarr or Dask), - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), - Presenting or running tutorials (such as those we have given at the SciPy conference), From 000e505ca7ba3a131445deac61b20fcf40f113ce Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:08:22 -0400 Subject: [PATCH 17/25] note that you don't have to do everything --- CORE_TEAM_GUIDE.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 49360a791b7..ef3d12e4632 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -40,8 +40,11 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Maintain xarray's various Continuous Integration Workflows, - Write code that goes into xarray `main`. -Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be interesting background reading, -but should not be taken to strictly apply to the Xarray project. +(Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be +interesting background reading, but should not be taken to strictly apply to the Xarray project.) + +Obviously you are not expected to contribute in all, or even more than one of these ways! They are listed so as to +indicate the many types of work that go into maintaining xarray. It is natural that your available time and enthusiasm for the project will wax and wane - this is fine and expected! It is also common for core team members to have a "niche" - a particular part of the codebase they have specific expertise From c7b8f23af94f3cfd42af0bace9e6c27a63491c2a Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:13:03 -0400 Subject: [PATCH 18/25] paragraph at top making it clear no extra work is required! --- CORE_TEAM_GUIDE.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index ef3d12e4632..0a4645f2552 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -7,9 +7,12 @@ your work, and enjoy working with you; we have therefore invited you to join us. Thank you for your numerous contributions to the project so far. +By accepting you are not required to commit to doing any more work - xarray is a volunteer project, +and we value the contributions you have made already. + You can see a list of all the current core team members on our [@pydata/xarray](https://github.com/orgs/pydata/teams/xarray) -GitHub team. You should now be on that list too. +GitHub team. Once accepted, you should now be on that list too. This document offers guidelines for your new role. ## Tasks @@ -31,7 +34,7 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Project organization (run / attend developer meetings, coordinate with sponsors), - Project evangelism (advertise xarray to new users), - Community contact (represent xarray in user communities such as [Pangeo](https://pangeo.io/)), -- Key project contact (represent xarray's perspective within key related projects like numpy, Zarr or Dask), +- Key project contact (represent xarray's perspective within key related projects like NumPy, Zarr or Dask), - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), - Presenting or running tutorials (such as those we have given at the SciPy conference), From 9acb87bc18c8f2ac6936d14d440d62d337074438 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:15:04 -0400 Subject: [PATCH 19/25] whatsnew --- doc/whats-new.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/whats-new.rst b/doc/whats-new.rst index 682b8cf3066..59554f67891 100644 --- a/doc/whats-new.rst +++ b/doc/whats-new.rst @@ -41,6 +41,8 @@ Documentation - Add docstrings for the :py:class:`Index` base class and add some documentation on how to create custom, Xarray-compatible indexes (:pull:`6975`) By `Benoît Bovy `_. +- Added a page clarifying the role of Xarray core team members. + (:pull:`7999`) By `Tom Nicholas `_. Internal Changes ~~~~~~~~~~~~~~~~ From 5b5d52d921c9c878b10143a6299f24d13daccb1c Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 13:34:22 -0400 Subject: [PATCH 20/25] add section on issue triage --- CORE_TEAM_GUIDE.md | 64 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 61 insertions(+), 3 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 0a4645f2552..207b57541ad 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -1,4 +1,4 @@ -> **_Note:_** This Core Team Member Guide was adapted from the [napari project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html). +> **_Note:_** This Core Team Member Guide was adapted from the [napari project's Core Developer Guide](https://napari.org/stable/developers/core_dev_guide.html) and the [Pandas maintainers guide](https://pandas.pydata.org/docs/development/maintaining.html). # Core Team Member Guide @@ -58,7 +58,65 @@ If however you feel that is unlikely you will be able to be actively contribute then you may want to consider letting us know you would rather be listed as an "Emeritus Core Team Member", as this would help us in evaluating the overall health of the project. -## Code contributions +## Issue triage + +One of the main ways you might spend your contribution time is by responding to or triaging new issues. +Here’s a typical workflow for triaging a newly opened issue or discussion: + +1. **Thank the reporter for opening an issue.** + + The issue tracker is many people’s first interaction with the xarray project itself, beyond just using the library. + As such, we want it to be a welcoming, pleasant experience. + +2. **Is the necessary information provided?** + + Ideally reporters would fill out the issue template, but many don’t. If crucial information (like the version of xarray they used), + is missing feel free to ask for that and label the issue with “Needs info”. + The report should follow the [guidelines for xarray discussions](https://github.com/pydata/xarray/discussions/5404). + You may want to link to that if they didn’t follow the template. + + Make sure that the title accurately reflects the issue. Edit it yourself if it’s not clear. + Remember also that issues can be converted to discussions and vice versa if appropriate. + +3. **Is this a duplicate issue?** + + We have many open issues. If a new issue is clearly a duplicate, label the new issue as “Duplicate” assign the milestone “No Action”, and close the issue with a link to the original issue. Make sure to still thank the reporter, and encourage them to chime in on the original issue, and perhaps try to fix it. + + If the new issue provides relevant information, such as a better or slightly different example, add it to the original issue as a comment or an edit to the original post. + +4. **Is the issue minimal and reproducible?** + + For bug reports, we ask that the reporter provide a minimal reproducible example. + See [minimal-bug-reports](https://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports) for a good explanation. + If the example is not reproducible, or if it’s clearly not minimal, feel free to ask the reporter if they can provide and example or simplify the provided one. + Do acknowledge that writing minimal reproducible examples is hard work. If the reporter is struggling, you can try to write one yourself and we’ll edit the original post to include it. + + If a reproducible example can’t be provided, add the “Needs info” label. + + If a reproducible example is provided, but you see a simplification, edit the original post with your simpler reproducible example. + +5. **Is this a clearly defined feature request?** + + Generally, xarray prefers to discuss and design new features in issues, before a pull request is made. + Encourage the submitter to include a proposed API for the new feature. Having them write a full docstring is a good way to pin down specifics. + + We may need a discussion from several xarray maintainers before deciding whether the proposal is in scope for xarray. + +6. **Is this a usage question?** + + We prefer that usage questions are asked on StackOverflow with the pandas tag. https://stackoverflow.com/questions/tagged/pandas + + If it’s easy to answer, feel free to link to the relevant documentation section, let them know that in the future this kind of question should be on StackOverflow, and close the issue. + +7. **What labels and milestones should I add?** + + Apply the relevant labels. This is a bit of an art, and comes with experience. Look at similar issues to get a feel for how things are labeled. + Labels used for labelling issues that relate to particular features or parts of the codebase normally have the form `topic-`. + + If the issue is clearly defined and the fix seems relatively straightforward, label the issue as `contrib-good-first-issue`. + + +## Code review and contributions As a core team member, you are a representative of the project, and trusted to make decisions that will serve the long term interests @@ -66,7 +124,7 @@ of all users. You also gain the responsibility of shepherding other contributors through the review process; here are some guidelines for how to do that. -## All contributors are treated the same +### All contributors are treated the same You should now have gained the ability to merge or approve other contributors' pull requests. Merging contributions is a shared power: From 129cf01d8ee4a8f1f90988be150629428c431b2c Mon Sep 17 00:00:00 2001 From: Tom Nicholas Date: Tue, 18 Jul 2023 16:13:59 -0400 Subject: [PATCH 21/25] Apply suggestions from Deepak's code review Co-authored-by: Deepak Cherian --- CORE_TEAM_GUIDE.md | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 207b57541ad..885807e2ef8 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -2,12 +2,11 @@ # Core Team Member Guide -Welcome, new core team member! The core team appreciate the quality of -your work, and enjoy working with you; we have therefore invited you -to join us. Thank you for your numerous contributions to the project +Welcome, new core team member! We appreciate the quality of +your work, and enjoy working with you! Thank you for your numerous contributions to the project so far. -By accepting you are not required to commit to doing any more work - xarray is a volunteer project, +By accepting you are **not required to commit to doing any more work** - xarray is a volunteer project, and we value the contributions you have made already. You can see a list of all the current core team members on our @@ -26,6 +25,7 @@ Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “e **There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). Rather, the tasks that follow are general descriptions of what it might mean to be a core team member: +- Facilitate a welcoming environment for those who file issue, make pull requests, and open discussion topics, - Triage newly filed issues, - Review newly opened pull requests, - Respond to updates on existing issues and pull requests, @@ -38,10 +38,12 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Project fundraising (help write and administrate grants that will support xarray), - Improve documentation or tutorials (especially on [`tutorial.xarray.dev`](https://tutorial.xarray.dev/)), - Presenting or running tutorials (such as those we have given at the SciPy conference), -- Maintain the [`xarray.dev`](https://xarray.dev/) landing page and website, the [code for which is here](https://github.com/xarray-contrib/xarray.dev), +- Help maintain the [`xarray.dev`](https://xarray.dev/) landing page and website, the [code for which is here](https://github.com/xarray-contrib/xarray.dev), - Write blog posts on the [xarray blog](https://xarray.dev/blog), -- Maintain xarray's various Continuous Integration Workflows, -- Write code that goes into xarray `main`. +- Help maintain xarray's various Continuous Integration Workflows, +- Contribute to the xarray codebase. +- Help maintain a regular release schedule (we aim for one or more releases per month) +- Attend the bi-weekly community meeting ([issue](https://github.com/pydata/xarray/issues/4001)). (Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be interesting background reading, but should not be taken to strictly apply to the Xarray project.) @@ -114,7 +116,8 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: Labels used for labelling issues that relate to particular features or parts of the codebase normally have the form `topic-`. If the issue is clearly defined and the fix seems relatively straightforward, label the issue as `contrib-good-first-issue`. - +8. **Where should the poster look to fix the issue?** + If you can, it is very helpful to point to the approximate location in the codebase where a contributor might begin to fix the issue. This helps easy the way for new contributors to the repository. ## Code review and contributions @@ -137,7 +140,7 @@ complex changes, wait until at least one other core team member has approved. It should also be considered best practice to leave a reasonable (24hr) time window after approval before merge to ensure that other core team members have a reasonable chance to weigh in. -Adding the "plan to merge" label notifies developers of the imminent merge. +Adding the `plan-to-merge` label notifies developers of the imminent merge. We are also an international community, with contributors from many different time zones, some of whom will only contribute during their working hours, others who might only be able @@ -226,7 +229,8 @@ branch yourself, force-push to their branch, and advise the contributor to force no longer active, you may take over their branch by submitting a new pull request and closing the original, including a reference to the original pull request. In doing so, ensure you communicate that you are not throwing the -contributor's work away! +contributor's work away! If appropriate it is a good idea to acknowledge other contributions +to the pull request using the `Co-authored-by` [syntax](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) in the commit message. ### Merge only changes you understand @@ -243,6 +247,8 @@ While we collectively "own" any patches (and bugs!) that become part of the code base, you are vouching for changes you merge. Please take that responsibility seriously. +Feel free to ping other active maintainers with any questions you may have. + ## Further resources As a core member, you should be familiar with community and developer @@ -275,7 +281,7 @@ This meeting is public, so we occasionally have non-core team members join us. We also have a private mailing list for core team members `xarray-core-team@googlegroups.com` which is sparingly used for discussions -that are required to be private, such as voting on new core members. +that are required to be private, such as nominating new core members and discussing financial issues. ## Inviting new core members @@ -284,7 +290,8 @@ While there is no hard-and-fast rule about who can be nominated, ideally, they should have: been part of the project for at least two months, contributed significant changes of their own, contributed to the discussion and review of others' work, and collaborated in a way befitting our -community values. After nomination voting will happen on a private mailing list. +community values. **We strongly encourage nominating anyone who has made significant non-code contributions +to the Xarray community in any way**. After nomination voting will happen on a private mailing list. While it is expected that most votes will be unanimous, a two-thirds majority of the cast votes is enough. From 06384f12431f97c5c103ec85aae80e388f800117 Mon Sep 17 00:00:00 2001 From: Thomas Nicholas Date: Tue, 18 Jul 2023 16:32:10 -0400 Subject: [PATCH 22/25] various fixes --- CORE_TEAM_GUIDE.md | 47 ++++++++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 20 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 885807e2ef8..cf1dc152d68 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -2,12 +2,11 @@ # Core Team Member Guide -Welcome, new core team member! We appreciate the quality of -your work, and enjoy working with you! Thank you for your numerous contributions to the project -so far. +Welcome, new core team member! We appreciate the quality of your work, and enjoy working with you! +Thank you for your numerous contributions to the project so far. -By accepting you are **not required to commit to doing any more work** - xarray is a volunteer project, -and we value the contributions you have made already. +By accepting the invitation to become a core team member you are **not required to commit to doing any more work** - +xarray is a volunteer project, and we value the contributions you have made already. You can see a list of all the current core team members on our [@pydata/xarray](https://github.com/orgs/pydata/teams/xarray) @@ -25,13 +24,13 @@ Xarray is mostly a volunteer project, so these tasks shouldn’t be read as “e **There are no strict expectations**, other than to adhere to our [Code of Conduct](https://github.com/pydata/xarray/tree/main/CODE_OF_CONDUCT.md). Rather, the tasks that follow are general descriptions of what it might mean to be a core team member: -- Facilitate a welcoming environment for those who file issue, make pull requests, and open discussion topics, +- Facilitate a welcoming environment for those who file issues, make pull requests, and open discussion topics, - Triage newly filed issues, - Review newly opened pull requests, - Respond to updates on existing issues and pull requests, - Drive discussion and decisions on stalled issues and pull requests, - Provide experience / wisdom on API design questions to ensure consistency and maintainability, -- Project organization (run / attend developer meetings, coordinate with sponsors), +- Project organization (run developer meetings, coordinate with sponsors), - Project evangelism (advertise xarray to new users), - Community contact (represent xarray in user communities such as [Pangeo](https://pangeo.io/)), - Key project contact (represent xarray's perspective within key related projects like NumPy, Zarr or Dask), @@ -41,15 +40,15 @@ Rather, the tasks that follow are general descriptions of what it might mean to - Help maintain the [`xarray.dev`](https://xarray.dev/) landing page and website, the [code for which is here](https://github.com/xarray-contrib/xarray.dev), - Write blog posts on the [xarray blog](https://xarray.dev/blog), - Help maintain xarray's various Continuous Integration Workflows, +- Help maintain a regular release schedule (we aim for one or more releases per month), +- Attend the bi-weekly community meeting ([issue](https://github.com/pydata/xarray/issues/4001)), - Contribute to the xarray codebase. -- Help maintain a regular release schedule (we aim for one or more releases per month) -- Attend the bi-weekly community meeting ([issue](https://github.com/pydata/xarray/issues/4001)). (Matt Rocklin's post on [the role of a maintainer](https://matthewrocklin.com/blog/2019/05/18/maintainer) may be interesting background reading, but should not be taken to strictly apply to the Xarray project.) -Obviously you are not expected to contribute in all, or even more than one of these ways! They are listed so as to -indicate the many types of work that go into maintaining xarray. +Obviously you are not expected to contribute in all (or even more than one) of these ways! +They are listed so as to indicate the many types of work that go into maintaining xarray. It is natural that your available time and enthusiasm for the project will wax and wane - this is fine and expected! It is also common for core team members to have a "niche" - a particular part of the codebase they have specific expertise @@ -68,12 +67,12 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: 1. **Thank the reporter for opening an issue.** The issue tracker is many people’s first interaction with the xarray project itself, beyond just using the library. - As such, we want it to be a welcoming, pleasant experience. + It may also be their first open-source contribution of any kind. As such, we want it to be a welcoming, pleasant experience. 2. **Is the necessary information provided?** Ideally reporters would fill out the issue template, but many don’t. If crucial information (like the version of xarray they used), - is missing feel free to ask for that and label the issue with “Needs info”. + is missing feel free to ask for that and label the issue with “needs info”. The report should follow the [guidelines for xarray discussions](https://github.com/pydata/xarray/discussions/5404). You may want to link to that if they didn’t follow the template. @@ -82,7 +81,8 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: 3. **Is this a duplicate issue?** - We have many open issues. If a new issue is clearly a duplicate, label the new issue as “Duplicate” assign the milestone “No Action”, and close the issue with a link to the original issue. Make sure to still thank the reporter, and encourage them to chime in on the original issue, and perhaps try to fix it. + We have many open issues. If a new issue is clearly a duplicate, label the new issue as “duplicate”, and close the issue with a link to the original issue. + Make sure to still thank the reporter, and encourage them to chime in on the original issue, and perhaps try to fix it. If the new issue provides relevant information, such as a better or slightly different example, add it to the original issue as a comment or an edit to the original post. @@ -93,7 +93,8 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: If the example is not reproducible, or if it’s clearly not minimal, feel free to ask the reporter if they can provide and example or simplify the provided one. Do acknowledge that writing minimal reproducible examples is hard work. If the reporter is struggling, you can try to write one yourself and we’ll edit the original post to include it. - If a reproducible example can’t be provided, add the “Needs info” label. + If a nice reproducible example has been provided, thank the reporter for that. + If a reproducible example can’t be provided, add the “needs mcve” label. If a reproducible example is provided, but you see a simplification, edit the original post with your simpler reproducible example. @@ -106,7 +107,7 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: 6. **Is this a usage question?** - We prefer that usage questions are asked on StackOverflow with the pandas tag. https://stackoverflow.com/questions/tagged/pandas + We prefer that usage questions are asked on StackOverflow with the [`python-xarray` tag](https://stackoverflow.com/questions/tagged/python-xarray). If it’s easy to answer, feel free to link to the relevant documentation section, let them know that in the future this kind of question should be on StackOverflow, and close the issue. @@ -116,8 +117,12 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: Labels used for labelling issues that relate to particular features or parts of the codebase normally have the form `topic-`. If the issue is clearly defined and the fix seems relatively straightforward, label the issue as `contrib-good-first-issue`. + You can also remove the `needs triage` label that is automatically applied to all newly-opened issues. + 8. **Where should the poster look to fix the issue?** - If you can, it is very helpful to point to the approximate location in the codebase where a contributor might begin to fix the issue. This helps easy the way for new contributors to the repository. + + If you can, it is very helpful to point to the approximate location in the codebase where a contributor might begin to fix the issue. + This helps ease the way in for new contributors to the repository. ## Code review and contributions @@ -167,7 +172,7 @@ constructive criticism on ideas and implementations, and remind yourself of how it felt when your own work was being evaluated as a novice. -`xarray` strongly values mentorship in code review. New users +``xarray`` strongly values mentorship in code review. New users often need more handholding, having little to no git experience. Repeat yourself liberally, and, if you don’t recognize a contributor, point them to our development guide, or other GitHub @@ -218,7 +223,8 @@ do so. Other changes may be *nitpicky*: spelling mistakes, formatting, etc. Do not insist contributors make these changes, but instead you should offer -to make these changes by [pushing to their branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork), or using GitHub’s [suggestion](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request) +to make these changes by [pushing to their branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork), +or using GitHub’s [suggestion](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/commenting-on-a-pull-request) [feature](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request), and be prepared to make them yourself if needed. Using the suggestion feature is preferred because it gives the contributor a choice in whether to accept the changes. @@ -230,7 +236,8 @@ no longer active, you may take over their branch by submitting a new pull request and closing the original, including a reference to the original pull request. In doing so, ensure you communicate that you are not throwing the contributor's work away! If appropriate it is a good idea to acknowledge other contributions -to the pull request using the `Co-authored-by` [syntax](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) in the commit message. +to the pull request using the `Co-authored-by` +[syntax](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors) in the commit message. ### Merge only changes you understand From 3f8c522133737ff7f1f741c94374289bb1e6d36e Mon Sep 17 00:00:00 2001 From: Tom Nicholas Date: Wed, 19 Jul 2023 19:08:54 -0500 Subject: [PATCH 23/25] Update CORE_TEAM_GUIDE.md Co-authored-by: Joe Hamman --- CORE_TEAM_GUIDE.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 885807e2ef8..8b4f16fe175 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -106,8 +106,9 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: 6. **Is this a usage question?** - We prefer that usage questions are asked on StackOverflow with the pandas tag. https://stackoverflow.com/questions/tagged/pandas - + We prefer that usage questions are asked on StackOverflow with the [`python-xarray` tag](https://stackoverflow.com/questions/tagged/python-xarray +) or as a [GitHub discussion topic](https://github.com/pydata/xarray/discussions). + If it’s easy to answer, feel free to link to the relevant documentation section, let them know that in the future this kind of question should be on StackOverflow, and close the issue. 7. **What labels and milestones should I add?** From ffe09c12d57f0bf737c94fb885a57c26f96d418e Mon Sep 17 00:00:00 2001 From: "pre-commit-ci[bot]" <66853113+pre-commit-ci[bot]@users.noreply.github.com> Date: Thu, 20 Jul 2023 00:09:51 +0000 Subject: [PATCH 24/25] [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --- CORE_TEAM_GUIDE.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 8b4f16fe175..f94d81df4ac 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -107,8 +107,8 @@ Here’s a typical workflow for triaging a newly opened issue or discussion: 6. **Is this a usage question?** We prefer that usage questions are asked on StackOverflow with the [`python-xarray` tag](https://stackoverflow.com/questions/tagged/python-xarray -) or as a [GitHub discussion topic](https://github.com/pydata/xarray/discussions). - +) or as a [GitHub discussion topic](https://github.com/pydata/xarray/discussions). + If it’s easy to answer, feel free to link to the relevant documentation section, let them know that in the future this kind of question should be on StackOverflow, and close the issue. 7. **What labels and milestones should I add?** From 1946d14ff0adc1377da66a64f2b7cd570f19a7dd Mon Sep 17 00:00:00 2001 From: Tom Nicholas Date: Fri, 21 Jul 2023 09:21:35 -0400 Subject: [PATCH 25/25] How to run benchmark CI using PR label --- CORE_TEAM_GUIDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CORE_TEAM_GUIDE.md b/CORE_TEAM_GUIDE.md index 9ebb045df58..9eb91f4e586 100644 --- a/CORE_TEAM_GUIDE.md +++ b/CORE_TEAM_GUIDE.md @@ -196,6 +196,7 @@ large multidimensional datasets, high performance is a key value of `xarray`. Wh every new feature won't scale equally to all sizes of data, keeping in mind performance and our [benchmarks](https://github.com/pydata/xarray/tree/main/asv_bench) during a review may be important, and you may need to ask for benchmarks to be run and reported or new benchmarks to be added. +You can run the CI benchmarking suite on any PR by tagging it with the ``run-benchmark`` label. 3. **APIs and stability:** Coding users and developers will make extensive use of our APIs. The foundation of a healthy ecosystem will be