APE 22 follow-up: Update Affiliated guidelines and process

[pllim]

Update the files in https://github.com/astropy/astropy-project/tree/main/affiliated as per https://github.com/astropy/astropy-APEs/blob/main/APE22.rst .

This is a follow up of:

• Affiliated Package: Consolidate with pyOpenSci? #334
• APE 24: Astropy Affiliated Packages with pyOpenSci (now APE 22) astropy-APEs#87

Related:

• Feat: add text associated with astropy partnership pyOpenSci/software-peer-review#225
• FEAT: Community package listing pages for astropy + SunPy pyOpenSci/pyopensci.github.io#207
• https://pyopensci.discourse.group/t/astropy-partnership-next-steps/432/7

cc @dhomeier @WilliamJamieson @hamogu

[dhomeier]

Minor related issue: should we update the text of the APE itself to refer to (pre-)APE 22 instead of 24?

[pllim]

Good catch. Since this is trivial typo fix, I just did it directly at astropy/astropy-APEs@d834e63

[lwasser]

hey there 👋 everyone! we have a few open pr's that we will need to also flesh out - gosh opened during the summer.

1. peer review guide - partner page added for astropy - i think a handful of folks have reviewed this but might still need a few sets of eyes.
2. website: i've done a bit more work on this pr as well

what is the best way to get approval / feedback etc for these pages? i wouldn't want to merge until folks here are comfortable.

@pllim it's so good we did all of this legwork over the spring and summer. 🚀

[pllim]

@lwasser

Re: peer review guide -- I left comments.

Re: website -- I left comments but I really don't have a lot of opinions on website designs. I pinged some people too.

what is the best way to get approval / feedback etc for these pages?

Once I approve (FWIW), I can bring it up in a few different channels (e.g., Slack, astropy-dev, dev telecon). Then after a "comment period" (usually at least 2 weeks), I would say they are good to go if no objections. Sometimes people only reply when it is too late, but by then, they can always open follow-up PR; it is not the end of the world.

---

BTW, looking at https://github.com/astropy/astropy-project/blob/main/affiliated/affiliated_package_review_guidelines.md now, is there an obvious way to translate the "red"/"orange"/"green" into something that is compatible with how pyOpenSci operates? This question is for both Leah and current Astropy Editors.

When I was an Astropy Editor myself, I had always found "orange" and "green" confusing. AFAIK neither blocks Affiliated status, and the line between "orange" and "green" sometimes gets blurry depending on which reviewer you get and how nitpicky they are. Now that reviewer is not anonymous anymore, maybe we can do something completely different.

For each of the categories, for things that a reviewer deems missing, maybe they can open issues straight to the repo and cross-link back to the application PR with a note on which is a blocker and which isn't. Does this align with pyOpenSci or did I veer too far off?

I think the checklist in https://www.pyopensci.org/software-peer-review/how-to/reviewer-guide.html already covers most of the stuff, except the following:

• 'functionality' should be renamed to something that says "relevance to astronomy" (can be reworded). We can keep the existing "out of scope", "specialized", and "general". While "out of scope" is technically a rejection, the other two are only informational. So maybe this can be also a checkbox and with a note whether it is specialized or general?
• 'ecointegration' should be reduced to a checkbox and notes on whether any open issues would block the box being checked?

I don't think we need a Python 3 check anymore.