-
Notifications
You must be signed in to change notification settings - Fork 33
enh(policy): Add discussion about submission volume #357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
lwasser
left a comment
There was a problem hiding this 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). |
There was a problem hiding this comment.
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
lwasser
left a comment
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good.
yeelauren
left a comment
There was a problem hiding this 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
| At any given time, all points of contact across all active submissions (those | ||
| under review) should be unique. |
There was a problem hiding this comment.
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"
| ### 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. | ||
|
|
There was a problem hiding this comment.
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
| - 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - 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. |
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.