-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: update archive package text #258
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made a few suggestions to help add clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! In general, this LGTM except for the minor comments.
hi everyone - this task popped up in my asana list for today. i'm going to work on all of the feedback and such in the upcoming days with the goal of merging it next week by Wednesday dec 6. |
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
Co-authored-by: Carol Willing <[email protected]>
ok everyone. i'm ready to tackle this one again. I've just integrated some of your changes into the archive policy! i'm proposing:
activity would be quantified by: commits, pr's, releases The alternative is we just give maintainers a full year. (12 months) in terms of Ci builds that will be slightly easier to implement. thoughts? |
Good point about implementation. |
Co-authored-by: Carol Willing <[email protected]>
ok - yes for implementation purposes it's much easier to track the last updated date. (i can add to our current system and write a bit of code to look for pr's, commits, releases ). then on the front end of the website, it can check the date, determine how long it's been since we've see "activity" and add or not add a flag to the package listing. This is a really easy check for me to build with our current infrastructure! |
language is now this - it's a cleaner policy AND easier to implement so i appreciate both
|
i've also created a local task to do a bit more web dev when we add the astropy landing page to our site (after the APE is approved) it will look something like this: BACKEND dev:
FRONT END DEV (what people see on the website)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking very good :D Thanks @lwasser
Added #268 to repo to track future revision steps. Let's get this PR merged 😄 |
thank you so much @willingc i just pushed the last round of edits to this PR. and will merge now once all is "green" ✅ @hamogu @pllim thank you. both as well for the feedback and input. And please know as we implement the maintianed "Status" of a package we can always adjust our policies as it makes sense for all of our community partners and our maintainer community as well. but i'm very excited to know that the initial checks are something i know how to build based on our existing infrastructure!! so we really are not that far away from implementing this with our existing builds. |
All green !!! 🚢 !!! |
closes #254
this PR addresses the topic discussed in #254 it adds language around what we track and how we flag packages that may be en route to becoming orphans / unmaintained.
it is now open for formal review from the community.