You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -151,160 +151,112 @@ If you need help getting your package ready for review, you can submit a help re
151
151
152
152
### <iclass="fa-brands fa-github-alt"style="color:#81c0aa;"></i> Understanding our GitHub issue submission process
153
153
154
-
When you submit your package for review, you will **fill out a GitHub issue template**. This structured template helps our editorial board evaluate your package efficiently.
154
+
When you submit your package for review, you will **fill out a GitHub issue template**. This structured template helps our editorial board evaluate your package efficiently. This section helps you understand the elements of the template.
155
155
156
-
To keep the process smooth and ensure your package is reviewed efficiently:
156
+
### <iclass="fa-solid fa-check"style="color:#81c0aa;"></i> Guidelines for filling out the issue template
157
157
158
-
✔ **Complete all sections:** Even if something doesn’t apply, leave it as is.
159
-
✔ **Do not change the template format:** Keep section headers, bullet points, and structure intact.
160
-
✔ **Submit once your issue is fully complete:** Avoid continuous edits to the issue after your submit whenever possible.
158
+
***Complete all sections of the template.** If you have questions about fields, you can ask about them in the review issue.
159
+
***Do not modify existing formatting:** Please do not modify the template structure by adding elements to the template fields such as bold, italics, etc.
160
+
***Submit your issue only when fully completed:** If you can, try to avoid submitting an issue and then continuously editing it. If you'd like to work on the issue over time, consider forking our repository and working on the issue in your fork before submitting it as an option.
161
+
***If you made a pre-submission enquiry**, paste the link to the corresponding issue in your issue submission to link your submission request to the pre-submission discussion.
161
162
162
163
<divclass="notice notice--info"markdown="1">
163
-
<iclass="fa-solid fa-circle-exclamation"style="color:#81c0aa;"></i> **Why does this matter?**
164
+
<iclass="fa-solid fa-circle-exclamation"style="color:#81c0aa;"></i> **Why does filling out our review template matter?**
164
165
Our peer review workflow relies on scripts to process submission data. If the template structure is modified, it will break our automated processes!
# All of the fields below will be filled out by out editorial team
178
+
EiC: TBD
179
+
Editor: TBD
180
+
Reviewer 1: TBD
181
+
Reviewer 2: TBD
182
+
Archive: TBD
183
+
JOSS DOI: TBD
184
+
Version accepted: TBD
185
+
Date accepted (month/day/year): TBD
186
+
```
177
187
178
-
####<iclass="fa-solid fa-pen-to-square"style="color:#81c0aa;"></i> Writing and previewing your issue
188
+
### <i class="fa-solid fa-users" style="color:#81c0aa;"></i> Community partnerships
179
189
180
-
- Fill out your issue in the **Write** tab.
181
-
- Click the **Preview** tab to see how your submission will appear once posted.
190
+
We collaborate with domain-specific organizations to ensure high-quality reviews. If you are interested in becoming an affiliated project associated with one of our partners, you can click on the partner that your package's scope aligns with. Our most active partnership is with [Astropy](https://www.pyopensci.org/software-peer-review/partners/astropy.html).
182
191
183
-
Check that all required fields are filled out before submitting.
192
+
If your package fits within one of our partnerships, we will assign an editor who is able to review your package for both OpenSci requirements and the affiliation project affiliation.
184
193
185
-
One of the quirky things about the pyOpenSci submission template is that the checkboxes have two different methods for completion:
186
-
* You can manually add an "X" in the box to mark it as checked,
187
-
* or you can check it off after you submit the issue by clicking on the corresponding boxes.
<img src="/images/peer-review/pyos-partnerships-peer-review.png" alt="A flowchart showing how a package submitted to pyOpenSci can also be fast-tracked for JOSS publication." style="width: 70%; display: block; margin: 0 auto;">
197
+
<figcaption>
198
+
Packages accepted into pyOpenSci can also be published in JOSS through a streamlined process.
193
199
194
-
-**Headers:** Use `#` for section titles (`##` for subheaders).
195
-
-**Bullet points:** Use `-` or `*` to create lists.
196
-
-**Checkboxes:** Use `[ ]` for an empty box, `[X]` to check it off.
197
-
-**Bold text:** Use `**bold**` to emphasize words.
198
-
-**Italic text:** Use `*italics*` for softer emphasis.
200
+
</figcaption>
201
+
</figure>
199
202
200
-
Need more Markdown help? Check out this [Markdown Guide](https://www.markdownguide.org/basic-syntax/).
203
+
### <i class="fa-solid fa-pen-to-square" style="color:#81c0aa;"></i> Double check your your submission before hitting submit
201
204
202
-
### <iclass="fa-solid fa-circle-check"style="color:#81c0aa;"></i> Final checklist before submitting
205
+
Before submitting your issue, double-check that all fields are filled out correctly. You can use the GitHub preview tab to ensure the issue looks correct. Check the following things:
203
206
204
207
✅ The issue is **fully completed**
205
208
✅ The template **formatting has not been changed**
206
209
✅ The **Write tab preview looks correct**
207
210
208
-
Once you're ready, **submit your issue**, and our editors will take it from there! 🚀
209
-
211
+
## TODO: add screenshot of the preview
210
212
211
-
### <iclass="fa-solid fa-map"></i> Step-by-step guide to completing the pyOpenSci software review issue template
212
-
213
-
When completing your package submission, it's best to submit the issue all at once, rather than completing it over the course of several sessions. We recommend reading through the issue once or twice to see what information you'll need, which includes:
214
-
215
-
* The scope of your package (see categories)
216
-
* Your target audience
217
-
* Scientific applications of your package
218
-
* Other packages that accomplish the same thing (if any), and how yours is different
213
+
<div class="notice notice--tip" markdown="1">
214
+
One of the quirky things about the pyOpenSci submission template is that checkboxes have two completion methods:
215
+
- You can manually add an "X" inside the box (`[X]`).
216
+
- Or, after submission, click the box to check it off.
217
+
</div>
219
218
220
-
> Remember: keep the formatting of the issue template exactly as it is! It's OK to leave sections that don't apply to you blank, and there's no need to add any additional formatting (bolding, italicizing, etc.). Any of these types of changes make it more difficult for our editorial team to process your package submission.
219
+
Need more Markdown help? Check out this [Markdown Guide](https://www.markdownguide.org/basic-syntax/).
221
220
222
-
#### Package metadata
223
221
224
-
***Add a title:** keep your title simple. Oftentimes your package name and the word submission is enough, such as "My Amazing Python package submission."
225
-
***Add a description** in this section you'll want to fill out the Submitting Author, All current maintainers, Package Name, One-Line Description of Package, Repository Link, and Version submitted sections. You should *not* fill out the EiC, Editor, Reviewer 1, Reviewer 2, Archive, JOSS DOI, Version accepted, or Date accepted sections. Instead, leave these as is, with "TBD."
222
+
Once you're ready, **submit your issue**, and our editors will take it from there! 🚀
226
223
227
224
#### Code of Conduct & Commitment to Maintain Package
228
225
229
226
In order for your package to progress through the pyOpenSci review process, you'll need to check both of the [Code of Conduct](https://www.pyopensci.org/handbook/CODE_OF_CONDUCT.html) agreement as well as the [maintenance agreement](https://www.pyopensci.org/software-peer-review/our-process/policies.html#after-acceptance-package-ownership-and-maintenance) outlined in the [pyOpenSci Policies Guidelines](https://www.pyopensci.org/software-peer-review/about/intro.html). You can indicate your agreement in one of two ways:
230
227
* adding an "X" (without quotation marks) inside the brackets in the Markdown version of the issue, so that it reads like this: [X]
231
228
* submitting the issue without making any changes to this section, and then clicking on the checkboxes when they're rendered in the submitted issue.
232
229
233
-
#### Description
234
-
235
-
This section is where you'll provide a brief description of your package. It's helpful to include information on what your package does, and how it helps to benefit the open science community. Sharing information about what your package allows users to do helps us get a clearer idea on the scope of your package, as well as help us identify editors and reviewers who will be a good fit for your review.
236
-
237
-
#### Scope
238
-
239
-
The mission of pyOpenSci’s open peer review process is to:
240
-
241
-
1. Support improving the quality, usability and discoverability of maintained scientific Python software in support of open science.
242
-
243
-
2. We also support maintainers in navigating the Python packaging ecosystem.
244
-
245
-
pyOpenSci reviews packages that support open reproducible science, data processing and the various stages of managing the data lifecycle. We review packages with the goal of improving package quality and usability for scientists. As such, we review packages across a spectrum of small to large user bases. The popularity of your package is not a consideration in our review process!
246
-
247
-
We welcome young packages that are just entering the scientific Python ecosystem to apply for review if they are relevant to the science community and fit into at least one scope category below. We also welcome mature packages with a growing or established community!
248
-
249
-
The following categories are in-scope for the pyOpenSci review process:
250
-
***Data retrieval:** refers to packages for accessing and downloading data from online sources, including wrappers for accessing APIs.
251
-
***Data extraction:** these packages aid in retrieving data from unstructured sources such as text, images, and PDFs. They might also parse scientific data types and outputs from scientific equipment.
252
-
***Data processing/munging:** this category focuses on tools for handling data in specific formats that scientists may be interested in working with.
253
-
***Data deposition:** includes tools for depositing data into scientific research repositories.
254
-
***Data validation and testing:** refers to tools that enable automated validation and checking of data quality and completeness that in turn support scientific workflows.
255
-
***Data visualization:** these are packages that enhance a scientist’s experience in visualizing and analyzing data. If your package falls into the category of data visualization, please fill out a [pre-submission inquiry](https://github.com/pyOpenSci/software-submission/issues/new?assignees=&labels=0%2Fpresubmission&template=presubmission-inquiry.md&title=) first.
256
-
***Workflow automation:** these tools automate and link together workflows, and as such support reproducible workflows. These tools may include build systems and tools to manage continuous integration, as well as support version control.
257
-
***Citation management and bibliometrics:** these are packages that facilitate managing references.
258
-
***Scientific software wrappers:** these tools provide a Python interface for existing scientific packages written in other languages.
259
-
***Database interoperability:** these packages deal with bindings and wrappers for database APIs.
260
-
261
-
Similar to the previous section, you can indicate which categories are applicable to your package in one of two ways:
262
-
* adding an "X" (without quotation marks) inside the brackets in the Markdown version of the issue, so that it reads like this: [X]
263
-
* submitting the issue without making any changes to this section, and then clicking on the checkboxes when they're rendered in the submitted issue.
264
-
265
-
You can read more about each of these categories in the [Package Scope](https://www.pyopensci.org/software-peer-review/index.html) section of the [pyOpenSci Peer Review Guide](https://www.pyopensci.org/software-peer-review/about/package-scope.html).
266
-
267
-
#### Domain specific
268
-
269
-
This section is currently evolving, and it's OK if your package doesn't fit into a specific listed domain.
270
-
271
-
#### Community Partnerships
272
-
273
-
Similar to the Domain specific section, our Community Partnerships are continuously growing and changing, and it's OK if your package isn't affiliated with one of the listed partners.
274
-
275
-
#### For all submissions
230
+
<!-- #### For all submissions
276
231
277
232
This section is important, as it helps us more holistically evaluate your package and determine whether or not it's a good fit for pyOpenSci review. Each of the following sections should be addressed/answered:
278
233
* *Explain how and why the package falls under the categories you indicated above.* Here's where you'll provide us with information that connects your package and its functionality to both its domain and technical capabilities.
279
234
* *Who is the target audience and what are scientific applications of this package?* This helps us understand who will be using the package.
280
235
* *Are there other Python packages that accomplish the same thing? If so, how does yours differ?* This helps us get a handle on other packages that fall within the same domain, as well as ensure that efforts aren't being duplicated.
281
-
**If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or `@tag` the editor you contacted.* This is an important section, as it links your pre-submission inquiry with your submission.
282
-
283
-
#### Technical checks
284
-
285
-
It's important that your package meet each of the qualifications in this section. If you are missing one or more of these items, you can learn more about how to implement them in our [pyOpenSci Packaging Guide](https://www.pyopensci.org/python-package-guide/). Taken as a whole, these components represent best practices in Python packaging, and as such its important that they be present in all pyOpenSci-approved packages.
236
+
-->
286
237
287
238
#### Publication Options
288
239
289
240
One of the benefits of submitting your package to pyOpenSci for review is that once it's approved, it can be fast-tracked for publication with [JOSS](https://joss.theoj.org/). JOSS accepts pyOpenSci's review as theirs, and therefore you will not need to go through another full review. Instead, JOSS will only review your paper.md file.
290
241
291
-
#### Are you OK with Reviewers Submitting Issues and/or pull requests to your Repo Directly?
292
-
293
-
You'll notice that the section on having reviewers submit requested changes as issues to your package repositories is already checked. You do have the option of un-checking it, but we consider the benefits of this to be that people can contribute to your review repos. Open issues, PRs, etc. all help you as a maintainer, while also giving you the opportunity to address any issues via PR links.
294
-
295
242
#### Please fill out our survey
296
243
297
-
We know that surveys aren't necessarily your favorite thing to do, but completing the [pyOpenSci pre-review survey](https://forms.gle/F9mou7S3jhe8DMJ16) is a huge help to our team of volunteers, future package authors, and pyOpenSci as an organization. It helps us track submissions as well as continuously improve our peer review process.
244
+
Completing the [pyOpenSci pre-review survey](https://forms.gle/F9mou7S3jhe8DMJ16) is a huge help to our team of volunteers, future package authors, and pyOpenSci as an organization. It helps us track submissions as well as continuously improve our peer review process.
245
+
246
+
### <i class="fa-solid fa-hourglass" style="color:#81c0aa;"></i> What happens after you submit your package?
298
247
299
-
#### Editor and Review templates
248
+
Once you submit your package, our **Editor-in-Chief** will review it to confirm:
249
+
- <i class="fa-solid fa-check" style="color:#81c0aa;"></i> It fits within **pyOpenSci’s scope**
250
+
- <i class="fa-solid fa-check" style="color:#81c0aa;"></i> It meets **infrastructure and documentation requirements**
300
251
301
-
This isn't a section that you need to worry about! In fact, this is a great time to read through your issue one last time, and hit submit.
Now that you've submitted your package to pyOpenSci's peer review process, you can relax for a bit. Our Editor-in-Chief will review your submission for both its scope and infrastructure and determine whether or not it's a good fit for pyOpenSci. This process generally takes about two weeks, but may be shorter or longer depending on how many packages pyOpenSci currently has in review. The Editor-in-Chief will also use this time to ask for any necessary changes that may need to be made to your package, as well as give you time to implement them.
257
+
During this process, editors may request **minor updates** to help your package move forward smoothly.
306
258
307
-
Once the Editor-in-Chief has decided to move ahead with your package, we begin the review process with both editors and reviewers. On average, this takes approximately three months, but this timeframe can vary considerably depending on the package. You can read the detailed steps of what happens during the peer review process in the [pyOpenSci Peer Review Guide for Python Open Source Authors](https://www.pyopensci.org/software-peer-review/how-to/author-guide.html).
259
+
📖 **Read the full review process in our** [Peer Review Guide](https://www.pyopensci.org/software-peer-review/how-to/author-guide.html).
308
260
309
261
## <i class="fa-regular fa-comments"></i> Connect with us!
0 commit comments