Indicate, hide or de-prioritize deprecated projects on the showcase website

[chalu]

Projects marked as deprecated on the repo's README are not so reflected on the showcase website.

This leads to inconsistency on what is being communicated. and may make it somewhat difficult to decide between two similar projects if you can quickly tell that one is deprecated

[rotimi-best]

I agree, I just implemented a change that checks for archived and deprecated repos then shows it as a chip on the UI.

Ideally we should have like a filter on the projects list to hide archived or deprecated repos.

@kaf-lamed-beyt what do you think? I am working on a PR with this update.

[kaf-lamed-beyt]

LGTM!

@acekyd, @D-Lite is the color choice okay?

[acekyd]

The color choice looks good. On second thought however, a good thing to note is that the criteria for setting projects as deprecated were that the last commit was over 2 years ago (If I remember correctly). This process was also done manually - hopefully there could be an easy way to implement it in future.

However I'd like to change the intent to something else from deprecated - maybe like not actively maintained or something shorter - cos some of them still work and deprecated might not be the fitting term.

[D-Lite]

What do you think of unmaintained or inactive? @acekyd @kaf-lamed-beyt @chalu

[kaf-lamed-beyt]

"Inactive" has a nice ring to it.👌🏽

[rotimi-best]

+1 for "Inactive"

In my PR should I rename Deprecated in the README to Inactive?

[acekyd]

Yes @rotimi-best. Inactive does sound good.

[chalu]

Inactive sounds good to me as well

[rotimi-best]

@acekyd @kaf-lamed-beyt @chalu.

Here is my checklist for completion

1. Rename Deprecated to Inactive. docs: rename Deprecated to Inactive #310
2. Implement the parsing of the README on main and then rendering of the tag on each project.

[kaf-lamed-beyt]

Hi @rotimi-best, I think, it'll be best if we can sort of automate this, just like @acekyd suggested, instead of manually typing it.

One way to go about this would be to use the GitHub Commit REST API to get the last commit date, and compare if it is in the range @acekyd mentioned — 2 years in this case.

The payload's response includes the date, we can use that.

If you're not going to be able to work on it for now, that's absolutely cool... perhaps @acekyd can merge this PR, then we'd look for a way to work on it internally.

[rotimi-best]

@kaf-lamed-beyt It shouldn't be complicated, I can def work on it.

If I am implementing the automated approach of checking if it is archived or inactive, should I just remove the text in the README that mentions whether it is "Inactive" or "Archived" so it doesn't confuse anyone in the future as we add more projects?

[kaf-lamed-beyt]

Yes. you should remove it. Since It'll be automated now.

If you have any questions, let me know, I'd be happy to help.

[acekyd]

You can proceed to test this on any branch now since the data source now uses the local file system (#314) now @rotimi-best - for the automation check, lets keep the processing time in mind so we don't lock up the main thread and make it all slower running API requests for 200+ projects.