Skip to content

Conversation

@eliotwrobson
Copy link
Contributor

Added policy based on discussion on #349 which should resolve the issue. Written using Gen AI, so worth being a little detailed in this review.

@eliotwrobson eliotwrobson requested a review from lwasser November 29, 2025 06:44
@eliotwrobson eliotwrobson self-assigned this Nov 29, 2025
@eliotwrobson eliotwrobson linked an issue Nov 29, 2025 that may be closed by this pull request
Copy link
Member

@lwasser lwasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great!

If you are currently the point of contact for another package under review, please
wait until that review is complete before submitting another package.
For more details, see our [submission volume policy](../our-process/policies.html#submission-volume-and-maintainer-overlap).
Copy link
Member

@lwasser lwasser Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eliotwrobson , actually, this link is breaking CI.

what i suggest instead is to create a target at

policies.html#submission-volume-and-maintainer-overlap
that looks like this

(submission-volumne)=

Then your link here can look like this

[submission volume policy](submission-volume)

  internally linking to #../our-process/policies.html#submission-volume-and-maintainer-overlap; the file exists, but the hash '../our-process/policies.html#submission-volume-and-maintainer-overlap' does not

Copy link
Member

@lwasser lwasser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops - there is a broken link... i suggest using targets instead

When submitting a package, please make sure that your GitHub notification
settings are setup to notify you when you receive feedback on the review issue.

## Submission volume and maintainer overlap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good.

@lwasser lwasser requested a review from a team December 1, 2025 18:08
Copy link

@yeelauren yeelauren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This adds a lot of clarity, thank you @eliotwrobson @lwasser !


### Unique point of contact requirement

Each submission to pyOpenSci should have one unique point of contact per package.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Each submission to pyOpenSci should have one unique point of contact per package.
Each submission to pyOpenSci should have one point of contact per package.

super minor thing - using unique twice across these sentences is somewhat redundant and could be confusing: if there can only be one of something in a set, it is by definition unique within that set, so this makes me wonder if the use of unique here is supposed to mean something different than the use of unique in the next sentence.

Comment on lines +37 to +38
At any given time, all points of contact across all active submissions (those
under review) should be unique.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the language is a little database-like, like i know what you mean, but maybe a more plain language description is something like "each person listed as a point of contact may have only one submission under review at a time"

Comment on lines +53 to +60
### Edge cases and exceptions

We recognize that some situations may warrant exceptions to these guidelines.
For example, two closely related packages that would benefit from review by
the same editorial team may be handled together. We will evaluate edge cases
to this policy as they arise, and decisions will be made by the Editor-in-Chief
based on reviewer capacity and the specific circumstances of the submission.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i sort of think that adding this caveats section here would make it so that one would expect a caveats subsection for every rule that has caveats, rather than having a single caveats section for all policies like "all policies may have exceptions and etc. under the discretion of the editors..." but again extremely minor

Comment on lines +42 to +44
- Review feedback receives appropriate attention from maintainers
- Maintainers don't become overwhelmed managing multiple concurrent reviews
- Our volunteer reviewers and editors can focus their efforts effectively
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Review feedback receives appropriate attention from maintainers
- Maintainers don't become overwhelmed managing multiple concurrent reviews
- Our volunteer reviewers and editors can focus their efforts effectively
- Review feedback receives appropriate attention from maintainers.
- Maintainers don't become overwhelmed managing multiple concurrent reviews.
- Our volunteer reviewers and editors can focus their efforts effectively.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

POLICY: Volume of submission to protect our team

6 participants