Closed lwasser closed 1 month ago
sure, could definitely be done. we make the model how we want it to work! ideally we do any big changes like this before anyone is actually depending on the fine structure of it (idk how many people actually are, but if there are many then we would want some deprecation process).
we already have this one liner for directly copying fields from the Issue, so eg. we already have created_at
and closed_at
which come from the Issue
model, i'll PR grabbing labels now.
semantically i guess all of the contents of the ReviewModel
come from an issue so are technically IssueMeta
, but if it would be helpful to group the fields that we are directly copying from the issue api response then by all means!
Thank you so much @sneakers-the-rat ! If it helps - right now this package supports:
So those two builds are the only ones that our changes will impact given this is a specific-to-pyOpenSci package.
it's really nice to think this all through like you are doing. this project evolved from a small script i initially wrote that became increasingly more complex. the organizing that you are providing here is so so helpful!! thank you again!!
You have enough to do running the org, I figure it would be nice to have this be a "just works" thing you dont have to worry about. Happy to help ♥
Current we have a peer-review-metrics repo that supports gathering information on our current and past review status. The goal is to turn this into a dashboard for editors and the EiC to understand the current state of reviews while also collecting review metrics that I / we can use for reporting.
The current refactor is great but it broke a few things over in peer-review metrics (built with myst).
see this notebook as an example. One of the things that we want to access with our review issues is the labels. The labels tell us the status of a review, and we need that information to create our dashboard of current and previous reviews.
we also want to collect metadata on the issue such as date opened, date closed, etc.
I wonder if we create a separate object or add a subclass to ReviewModel that stores Issue metadata including
We may want to add to this in the future as well. @sneakers-the-rat what do you think makes sense structurally here for this?
Would something like
Make sense ?
i wasn't thinking about our little dashboard that i've been playing with when we merged! but i think your structure is still much much cleaner!
make sense as a subclass that captures metadata like labels,