Skip to content

Commit 968ba12

Browse files
committed
more simplication
1 parent 703a287 commit 968ba12

File tree

1 file changed

+55
-103
lines changed

1 file changed

+55
-103
lines changed

_pages/how-to-submit.md

Lines changed: 55 additions & 103 deletions
Original file line numberDiff line numberDiff line change
@@ -151,160 +151,112 @@ If you need help getting your package ready for review, you can submit a help re
151151

152152
### <i class="fa-brands fa-github-alt" style="color:#81c0aa;"></i> Understanding our GitHub issue submission process
153153

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.
155155

156-
To keep the process smooth and ensure your package is reviewed efficiently:
156+
### <i class="fa-solid fa-check" style="color:#81c0aa;"></i> Guidelines for filling out the issue template
157157

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.
161162

162163
<div class="notice notice--info" markdown="1">
163-
<i class="fa-solid fa-circle-exclamation" style="color:#81c0aa;"></i> **Why does this matter?**
164+
<i class="fa-solid fa-circle-exclamation" style="color:#81c0aa;"></i> **Why does filling out our review template matter?**
164165
Our peer review workflow relies on scripts to process submission data. If the template structure is modified, it will break our automated processes!
165166
</div>
166167

167-
### <i class="fa-solid fa-tags" style="color:#81c0aa;"></i> GitHub labels
168168

169-
When you submit an issue, GitHub automatically applies labels to categorize your submission.
170-
For a **new submission**, the following labels will appear:
169+
### <i class="fa-solid fa-eye-slash" style="color:#81c0aa;"></i> Sections you can ignore
171170

172-
- **`0/pre-review-checks`** – Indicates the package is in the initial review phase.
173-
- **`New Submission!`** – Marks it as a new review request.
171+
Some sections of the template are **for editors only** and should be left blank. These include:
174172

175-
No action is needed on your part—labels are applied automatically.
173+
- **Editorial assignments:** "EiC," "Editor," "Reviewer 1," "Reviewer 2"
174+
- **JOSS-specific fields:** "JOSS DOI," "Version accepted," "Date accepted"
176175

176+
```yaml
177+
# 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+
```
177187
178-
#### <i class="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
179189
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).
182191
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.
184193
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.
188-
189-
### <i class="fa-solid fa-code" style="color:#81c0aa;"></i> Markdown basics
190-
191-
The issue template is written in Markdown, a simple text formatting language.
192-
Here are the basics you need to know:
194+
<figure>
195+
<source srcset="/images/peer-review/pyos-partnerships-peer-review.webp" type="image/webp">
196+
<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.
193199
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>
199202
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
201204
202-
### <i class="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:
203206
204207
✅ The issue is **fully completed**
205208
✅ The template **formatting has not been changed**
206209
✅ The **Write tab preview looks correct**
207210
208-
Once you're ready, **submit your issue**, and our editors will take it from there! 🚀
209-
211+
## TODO: add screenshot of the preview
210212
211-
### <i class="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>
219218

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/).
221220

222-
#### Package metadata
223221

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! 🚀
226223

227224
#### Code of Conduct & Commitment to Maintain Package
228225

229226
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:
230227
* adding an "X" (without quotation marks) inside the brackets in the Markdown version of the issue, so that it reads like this: [X]
231228
* submitting the issue without making any changes to this section, and then clicking on the checkboxes when they're rendered in the submitted issue.
232229

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
276231

277232
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:
278233
* *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.
279234
* *Who is the target audience and what are scientific applications of this package?* This helps us understand who will be using the package.
280235
* *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+
-->
286237

287238
#### Publication Options
288239

289240
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.
290241

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-
295242
#### Please fill out our survey
296243

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?
298247

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**
300251

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.
252+
#### <i class="fa-solid fa-calendar-days" style="color:#81c0aa;"></i> Timeline overview
302253

303-
### <i class="fa-solid fa-hourglass"></i> What’s next: what happens after you submit your package for review
254+
- <i class="fa-solid fa-clock" style="color:#81c0aa;"></i> **Initial checks:** ~2 weeks (varies based on submission volume)
255+
- <i class="fa-solid fa-users" style="color:#81c0aa;"></i> **Full peer review:** ~3 months (depends on package complexity)
304256

305-
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.
306258

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).
308260

309261
## <i class="fa-regular fa-comments"></i> Connect with us!
310262

0 commit comments

Comments
 (0)