enh(policy): Add discussion of package length #358
Conversation
There was a problem hiding this comment.
I think these changes were made by an autoformatter? Either way, everything in here looks good and should probably add markdown formatting checks to CI.
about/package-scope.md
Outdated
|
|
||
| ### Package size and scholarly effort | ||
|
|
||
| PyOpenSci reviews packages that represent substantial scholarly effort and provide |
There was a problem hiding this comment.
| PyOpenSci reviews packages that represent substantial scholarly effort and provide | |
| pyOpenSci reviews packages that represent substantial scholarly effort and provide |
about/package-scope.md
Outdated
| The final decision on whether a package represents sufficient scholarly effort | ||
| rests with the editor and will be made on a case-by-case basis. | ||
|
|
||
| ```{note} |
There was a problem hiding this comment.
| ```{note} | |
| :::{note} |
just for consistency as we use colon fences throughout (works either way tho!)
There was a problem hiding this comment.
@lwasser I think this was changed on save with the autoformatter I was using. Is there a way to have colon fences enforced through autoformatting?
There was a problem hiding this comment.
@eliotwrobson what are you using here on save? I think either we need a consistent linter for markdown or turn off linting on save-- otherwise this will keep happening every commit/PR
There was a problem hiding this comment.
@yeelauren looking at it again, I think that the AI assistant I was using did this. I can change back without having to mess with my settings.
There was a problem hiding this comment.
@yeelauren raises a good point. Could we create an .editorconfig file? I set up pre-commit locally, (there are .precommit config files in most of our repos here) so when I commit, it will format the files for me. If you prefer format on save, we could create a .editorconfig file too and just use that for those who don't like pre-commit. I know some really dislike it.
There was a problem hiding this comment.
I think having an editorconfig is a good idea (I personally like format-on-save more than on commit). We should make a separate issue + PR for that though (I think this one is ready to go anyway).
about/package-scope.md
Outdated
| Our more flexible approach allows us to support useful scientific packages | ||
| that may be outside JOSS scope while maintaining our partnership for | ||
| packages that meet both organizations' criteria. | ||
| ``` |
about/package-scope.md
Outdated
| ```{note} | ||
| **Relationship to JOSS requirements:** | ||
| The Journal of Open Source Software (JOSS) requires packages to have at least |
There was a problem hiding this comment.
Let's also link to JOSS policies here for "validation" .
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. | ||
|
|
||
| ```{note} |
There was a problem hiding this comment.
| ```{note} | |
| :::{note} |
our-process/policies.md
Outdated
| but does not meet JOSS requirements (e.g., minimum lines of code), it will not be | ||
| eligible for JOSS fast-track review. See our [package scope guidelines](../about/package-scope.html#package-size-and-scholarly-effort) | ||
| for more details. | ||
| ``` |
| minimum line count, we expect packages to demonstrate sufficient complexity and | ||
| functionality to warrant a comprehensive peer review. | ||
|
|
||
| **General expectations:** |
|
@lwasser In the latest push, I believe all of the comments you raised have been addressed. |
lwasser
left a comment
lwasser
left a comment
There was a problem hiding this comment.
@eliotwrobson this looks good to me. I think @yeelauren requested changes, but I also don't see what those changes are, so maybe you've completed them!! I'm happy with merging this. I'll open a tiny pr to fix the lingering broken target/link. I don't understand why those are popping up in this pr but they are!
| for an individual developer | ||
| - We discourage "salami slicing" - breaking up functionality into artificially | ||
| small packages solely to generate multiple submissions | ||
| - Packages with fewer than approximately 1,000 non-comment, non-whitespace lines |
There was a problem hiding this comment.
Maybe note that unit tests are not counted toward the 1,000 lines minimum but are expected?
Updated the link to package scope guidelines for clarity.
| package size requirements), packages must still meet JOSS's specific criteria to | ||
| be eligible for JOSS fast-track submission. If your package is accepted by pyOpenSci | ||
| but does not meet JOSS requirements (e.g., minimum lines of code), it will not be | ||
| eligible for JOSS fast-track review. See our [package scope guidelines](package-size-effort) |
There was a problem hiding this comment.
I created this target in the other PR to avoid future broken links. I 'm realizing that we have three pr's here that need to reference each other. 🙃
There was a problem hiding this comment.
Might be good to try and push to lower the issue / PR count so we can reduce the overhead of stuff like that (I make mistakes like that all the time too!)
Summarized discussion in #351 and should be appropriate for closing the issue. Written using gen ai for summarizing.