enh(JOSS policy): Revise JOSS discussion #342
Conversation
There was a problem hiding this comment.
@eliotwrobson this is a great addition. And it aligns I think with the discussions we've had around this topic. I don't have any feedback and approve it as is. Let's see what others think and plan to merge next Monday incorporating any feedback that we get before then!
lwasser
added
peer-review-policy
our-process/policies.md
Outdated
|
|
||
| 1. Fast-Track Review (Editor-Only): | ||
| Your package is eligible for this fast-track review if it has been published by | ||
| JOSS within the last year and has not had a major version release (e.g., v1.x to v2.0) |
There was a problem hiding this comment.
Maybe mention semantic versioning or clarify "major version" consideration new dependencies & significant API modifications
There was a problem hiding this comment.
I think I'll change the language to "major changes in dependency, design, or API", since there are many packages that don't even make these changes on a new major version.
There was a problem hiding this comment.
Maybe something like "that conflict with, remove, or invalidate claims and statements made in the joss paper" or something? Adding functionality seems fine, but IG the thing that would be bad is if they stripped all the stuff that they wrote in the paper out for some reason.
There was a problem hiding this comment.
Not sure about others but I think the purpose is to make sure everything in an approved package goes through some kind of review (thinking of an example where a Joss package adds a large feature that's not well documented or very unintuitive).
our-process/policies.md
Outdated
| standards. This approach reduces the burden of a full review while ensuring the quality of the package | ||
| reflects its most recent version. | ||
|
|
||
| We will also keep in touch with you as a maintainer to support long-term maintenance. If you need to step down from maintaining your package, we will help find a new maintainer and/or help sunset the tool. |
There was a problem hiding this comment.
nit: should this go under the After acceptance: package ownership and maintenance heading? or, if it is here for increased visibility, maybe it can go in the top Publication with Journal of Open Source Software (JOSS) section, after this sentence:
This provides increased visibility for your package as a vetted tool within the scientific
Python ecosystem and access to our long-term maintenance support.
There was a problem hiding this comment.
Removed this line since it's redundant with the rest of the description in this page: f85b395
our-process/policies.md
Outdated
| standards. This approach reduces the burden of a full review while ensuring the quality of the package | ||
| reflects its most recent version. | ||
|
|
||
| We will also keep in touch with you as a maintainer to support long-term maintenance. If you need to step down from maintaining your package, we will help find a new maintainer and/or help sunset the tool. |
There was a problem hiding this comment.
We will also keep in touch with you as a maintainer to support long-term maintenance.
Isn't this rather general? Or is this specific to software also published in JOSS?
There was a problem hiding this comment.
I had this thought too. Is this the case for any packages reviewed by pyopensci?
There was a problem hiding this comment.
This is the case for every package accepted by pyOS. I'll go ahead and removed this since another comment pointed out that the placement isn't great (it should be clear from the statement above that it is being accepted as any other pyOS package).
lwasser
changed the title
There was a problem hiding this comment.
thank you for your work on this @eliotwrobson !! We have a lot of approvals from our editorial team at this point so let's merge!!
Add revised requirements for acceptance by pyOS if a JOSS publication already exists.