|
1 | | -# Aims and Scope |
2 | | -pyOpenSci aims to support Python packages that enable reproducible research and managing the data lifecycle for scientists. Packages submitted to pyOpenSci should fit into one or more of the categories outlined below. If you are unsure whether your package fits into one of these categories, please open an issue as a pre-submission inquiry. We will let you know if we are able to review it at this time. |
| 1 | +# pyOpenSci Open Peer Review Goals and Scope |
3 | 2 |
|
| 3 | +pyOpenSci has several goals to support the scientific Python open source |
| 4 | +community. |
4 | 5 |
|
5 | | -## Package Categories |
6 | | -- **Data retrieval:** Packages for accessing and downloading data from online sources. Includes wrappers for accessing APIs. |
7 | | -- **Data extraction:** Packages that aid in retrieving data from unstructured sources such as text, images and PDFs. |
8 | | -- **Data munging:** Tools for processing data from scientific data formats. |
9 | | -- **Data deposition:** Tools for depositing data in scientific research repositories. |
10 | | -- **Reproducibility:** Tools to scientists ensure that their research is reproducible. E.g. version control, automated testing, or citation tools. |
11 | | -- **Geospatial:** Packages focused on the retrieval, manipulation, and analysis of spatial data. |
12 | | -- **Education:** Packages to aid with instruction. |
13 | | -- **Data visualization:**\* Packages for visualizing and analyzing data. |
| 6 | +1. **Packages with overlapping functionality:** |
| 7 | +It's easy to find multiple packages on PyPi that perform that same tasks (or overlapping tasks). When you submit to us, we ask that you know about other packages in our system that may do similar things. This check will help us connect maintainers who are working on similar goals. It will also help us in the long term reduce the number of overlapping packages, in various states of maintainence on pypi. |
14 | 8 |
|
15 | | -\* Please fill out a pre-submission inquiry before submitting a data visualization package. See the notes below. |
| 9 | +2. **Improve package usability:** Documentation makes it easier for scientists to use your tools. Our review process looks at documentation, quick start vignettes (code samples to get started) to make it easier for new users to get started using your package. |
16 | 10 |
|
17 | | -### Notes on Categories |
18 | | -- pyOpenSci is young and this list is tentative. If your scientific Python package does not fit into one of the categories or if you have any other questions, we'd encourage you to open a pre-submission inquiry. We're happy to help. |
19 | | -- Data visualization packages come in many varieties, ranging from small hyper-specific methods for one type of data to general, do-it-all packages (e.g. matplotlib). pyOpenSci accepts packages that are somewhere in between the two. If you're interested in submitting your data visualization package, please open a pre-submission inquiry on first. |
20 | | -- Note that we cannot currently accept statistics and/or machine learning packages. We don't feel that we can give these the deep, thorough review that they require. |
| 11 | +3. **Standardize packaging:** There are many different ways to create a Python |
| 12 | +package. We will embrace community driven standards created by organizations |
| 13 | +such as Scientific Python and help maintainers create more consistent |
| 14 | +infrastructure for their packages. In the long term consistent infrastructure |
| 15 | +will make it easier for new contributors to contribute too. |
| 16 | + |
| 17 | +1. **Long term maintenance:** Most maintainers are not paid and thus work on tools |
| 18 | +in their free time. So what happens when a maintainer of a commonly used tool wants |
| 19 | +to step down? We will help maintainers find someone new to take over the reigns. |
| 20 | +If that doesn't make sense we will help the maintainer gracefully sunset the |
| 21 | +package. |
| 22 | + |
| 23 | +1. The need for community around and support for smaller Python packages that |
| 24 | +support open science. |
| 25 | + |
| 26 | +## Is Your Package in Scope For pyOpenSci Review? |
| 27 | +pyOpenSci reviews packages within a set of categories define below. |
| 28 | +If you are unsure whether your package fits into one of these categories, please |
| 29 | +open a [pre-submission inquiry via a GitHub Issue](LINK) to get feedback from |
| 30 | +one of our editors. We are happy to look at your package and help you understand |
| 31 | +whether it is in scope or not. |
| 32 | + |
| 33 | +```{include} ../scope.md |
| 34 | +``` |
21 | 35 |
|
22 | 36 | ## Package Overlap |
23 | | -pyOpenSci encourages competition among packages, forking and re-implementation as they improve options of users overall. However, as we want packages in the pyOpenSci suite to be our top recommendations for the tasks they perform, we aim to avoid duplication of functionality of existing Python packages in any repo without significant improvements. A Python package that replicates the functionality of an existing package may be considered for inclusion in the pyOpenSci suite if it significantly improves on alternatives by being: |
| 37 | +pyOpenSci encourages competition among packages, forking and re-implementation |
| 38 | +as they improve options of users. However, strive to make packages in the |
| 39 | +pyOpenSci suite to represent our top recommendations for the tasks that they |
| 40 | +perform. We aim to avoid duplication of functionality of existing Python |
| 41 | +packages in any repo without significant improvements. A Python package that |
| 42 | +replicates the functionality of an existing package may be considered for |
| 43 | +inclusion in the pyOpenSci suite if it significantly improves on alternatives by |
| 44 | +being: |
24 | 45 |
|
25 | 46 | - More open in licensing or development practices |
26 | | -- Broader in functionality (e.g., providing access to more data sets, providing a greater suite of functions), but not only by duplicating additional packages |
| 47 | +- Broader in functionality (e.g., providing access to more data sets, providing |
| 48 | +a greater suite of functions), but not only by duplicating additional packages |
27 | 49 | - Better in usability and performance |
28 | 50 | - Actively maintained while alternatives are poorly or no longer actively maintained |
29 | 51 |
|
30 | | -These factors should be considered as a whole to determine if the package is a significant improvement. A new package would not meet this standard only by following our package guidelines while others do not, unless this leads to a significant difference in the areas above. |
| 52 | +These factors should be considered as a whole to determine if the package is a |
| 53 | +significant improvement. A new package would not meet this standard only by |
| 54 | +following our package guidelines while others do not, unless this leads to a |
| 55 | +significant difference in the areas above. |
31 | 56 |
|
32 | | -We recommend that packages highlight differences from and improvements over overlapping packages in their README and/or vignettes. |
| 57 | +We recommend that packages highlight differences from and improvements over |
| 58 | +overlapping packages in their README and/or vignettes. |
33 | 59 |
|
34 | | -We encourage developers whose packages are not accepted due to overlap to still consider submittal to other repositories or journals. |
| 60 | +We encourage developers whose packages are not accepted due to overlap to still |
| 61 | +consider submittal to other repositories or journals. |
0 commit comments