Agenda for November Meeting
===

###### tags: `Agenda` `Meeting` `JOSE`

:::info
- **Location:** [Zoom Link](https://umich.zoom.us/j/93322248562)
- **Date:** Nov 16, 2021 11:30 AM (EST)
- **Agenda**
1. Changes to documentation guidance to reflect discussions on scope
* Current Documentation: [Submitting a Paper Link](https://github.com/openjournals/docs/blob/jose/submitting.md)
* Module vs. Lesson language
2. Review Refresher
* Bringing on new reviewers
3. Editorial Guidelines

- **Host:** Jordan Gorzalski
:::

## Meeting Minutes

1. **Documentation Changes:**
* Allison H: yes we need to define it
* Chuck S: Module vs. Lesson is never really defined well in any community. With an e.g. somewhere something along the lines of "what might roughly be a week of a college course"
* Lorena B: Is this substantial enough work to acquire a DOI? Days/weeks/iterative improvement three weeks of a college course equivalent is the original bar. We won't exclude short content, but if it's being submitted it should be accompanied by other measures of scholarship.
* Jason W: College course could be one section for two hours. Maybe we should be transparent that this is a multi-dimensional problem. You could have content that is short but very useful, could also have extremely complicated content that's now been simplified. How many hours to develop? How often has it been iterated? Use a point/formula system?? Give a better idea of our system, our internal bar. One hour of teaching may have had 2 years of work behind it. Gives us at least a general idea of what people are coming from. Send points system to recently published papers and ask people to self score to figure out how this could work/what to look for.
* Shannon Q: What could this point system look like?
* Jason W: Time behind the effort? Time the user uses the content? Time of iteration/sessions of use and tweaking? Keep it simple in the documentation, right at the beginning before even submitting.
* Lorena B: How would this apply to software submissions?
* Jason W: Maybe we need a different system for the software side of things? Need to keep it simple.
* Lorena B: We don't want to make subjective assessments about novelty or impact.
* Chuck S: If the paper lacks the impact/interest then that should be enough of a metric. Would assume that the paper would tell us the story of the thing (software, teaching materials) being submitted and why it matters.
* Lorena B: So this should be in the statement of need.
* Allison H: CONDA Environments paper has been a struggle, what are the other pieces that warrant publication?
* Jason W: You could have great numbers but the paper is terrible - reject it. It's really more of a self-check before submitting, not a guarantee that you will be published.
* Shannon Q: The scoring system sets a reasonable baseline for further consideration
2. **Review Refresher:**
* Lorena B: Please check-in on papers you are handling bi-weekly. Also please try to not ask the same reviewers over and over. You can check to see how many papers a reviewer is doing from the JOSE Dashboard down at the bottom, just search the reviewers Git handle.
* Shannon E: Could we add reviewers who are busy for roughly a month to Slack? Just drop a note or something so that people are aware?
* Lorena B: Reach out to people who've just been published and ask if they'd like to review - give back to the community, etc. These things, not asking the same reviewers over and over, we should invest here now to grow the community. Finding reviewers is the hardest part of our job.
3. **Other Questions:**
* Shannon E: Deadline for reviews? How long do we want to take or estimate?
* Lorena B: That varies based on quality of paper/submit. Will always be a request and will always be late - soft deadlines. If it goes beyond 2 months, pause the review and get back to us when you're ready to restart. Can also pop in and ask author for an idea of timeline and then set a reminder for the author.
* Shannon Q: A few reviewers have fallen off the face of the earth.
* Lorena B: At some point you can make an executive decision to push something through to publication with only one reviewer. Reviewers are *not* gatekeepers.
4. **Ideas for module documentation language changes (*Please dump your thoughts here!***):