Repository navigation
Have a roadmap to re-review existing affiliated packages #139
Description
We have collected a number of affiliated packages over the years (42 at the time of writing this). To ensure that the quality of being an affiliated package is maintained, there is a need to go back and re-review them.
Possible outcome for an existing affiliated package:
- Stay affiliated: If badges remain the same or have improved overall.
- Get unaffiliated (after a grace period for the package to try to fix problems): If the package is outright abandoned, or badges have worsened overall, or any of the badges turns red.
cc @hamogu and @astropy/coordinators
Reacted by Erik Tollerud
Reacted by Juan Luis Cano Rodríguez and Thomas Robitaille
Activity
astrofrog commentedon Sep 25, 2020
I agree with this!
pllim commentedon Oct 9, 2020
Sorted the existing affiliated packaged (not coordinated) by last updated. Is this a good place to start, by going down this list?
p.s. Found a bug! astropy/astropy#10823
Update: Changed
statmorphdate due to developer-initiated re-review (astropy/astropy.github.com#421)adrn commentedon Oct 9, 2020
What does "last updated" mean?
pllim commentedon Oct 9, 2020
Not sure... Maybe CoCo knows?
adrn commentedon Oct 9, 2020
I only ask because it's definitely not the date that each package was last updated (gala has a release from July 2020 and commits from days ago), so it must be a log of when the affiliated package record was last updated..?
adrn commentedon Oct 9, 2020
Oh yea, they seem to be static values from the affiliated package JSON file - sorry for the noise!
pllim commentedon Oct 9, 2020
Looks like @bsipocz explained it at https://github.com/astropy/astropy.github.com/pull/382/files#r448593260
I think this date is for the review status and relevant to see when the package needs a rereview, etc.
astrofrog commentedon Oct 9, 2020
Yes just confirming it is when the review results were last updated. We could rename the key to include review perhaps?
eteq commentedon Oct 9, 2020
I also agree with doing this and confirm that that date was intended for exactly the purpose here (to know when to re-review).
That said... I feel like there's an argument for trying to hold the number at 42... 😉
pllim commentedon Oct 16, 2020
@hamogu , how about we plan to start the cycle, say Jan 2021, and strive to re-review one package every 2 months? (That will only take us 7 years...)
astrofrog commentedon Oct 16, 2020
7 years assuming no new packages!
pllim commentedon Oct 16, 2020
We could try parallel processing but will need more cores. 🤓
astrofrog commentedon Oct 16, 2020
Hopefully would work better than the io.ascii parallel reader?
pllim commentedon Jun 6, 2023
Also see #334 . I think we're leaning towards automation and not a full re-review.