Problem/Motivation
@drumm has brought up concerns about this in a few Slack threads and issues where making this decision was not quite in the scope. They're good points so I think they should get a dedicated issue.
From #3284347: Security Advisory icon/link problems
I don’t think “actively maintained” is good to call out with an icon. It is often stale information, and “actively” is subjective anyway. I don't think it is useful to know when evaluating projects.
Some of the other values, like “Obsolete” and “Unsupported” are useful information. They are likely accurate, and are a definite reason to be cautious of a project. I think these should be shown as negative indicators.
This follows what we do on Drupal.org project pages like https://www.drupal.org/project/swiftmailer. Negative indicators are called out with an orange triangle with an exclamation point. “Minimally maintained” is not necessarily negative, it could be a straightforward project that only needs minimal maintenance, so it gets a more-neutral grey triangle. The implementation of that is at https://git.drupalcode.org/project/drupalorg/-/blob/e31465608d1380345834...
That said, we could change the options, labels, or descriptions any time on Drupal.org, and we can not be stuck waiting for a core upgrade cycle to make that sort of change. So this information should probably come directly from Drupal.org’s API with minimal processing.
From Slack
I still think showing “actively maintained” is not helpful. That data gets stale and is subjective. Like we do on Drupal.org project pages, I recommend not showing anything for “actively maintained”, and only calling out negative indicators like “No further development” & “Unsupported”
From Slack
I still think it's the reverse of what is useful for people. “Maintained” could mean just about anything, there are no promises a maintainer will keep working or proactively update the status. Showing an icon for that is clutter. We have some clear warnings that are good information instead.
If we decide this should in fact be removed, we'd have the added benefit of avoiding some of the image-tweaking currently needed in #3267678: Use icon to assist with understanding of maintenance status
Update July 7
@drumm also said this in Slack, in response to this issue being created
Those labels are kinda misleading and vague. Would an average site builder know what “maintained” and “active” meant. They actually are pretty meaningless, as I’ve said. I’m more concerned about the icons on the project cards than the search criteria. For example, there should be nothing for “Actively maintained,” instead “Unsupported” should be called out. There should be nothing for “Active” development status, “No further development” & “Obsolete” should be called out.
The criteria is really secondary to the icon on the project cards. I’d design it as figuring out the project card first, then worry about filtering criteria matching.
The project cards are the first thing someone will see, before filtering
Steps to reproduce
Proposed resolution
Remaining tasks
- ✅ File an issue about this project
- ☐ Manual Testing
- ☐ Code Review
- ☐ Accessibility Review
- ☐ Automated tests needed/written?
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | Screenshot 2022-07-15 at 19.54.47.png | 184.75 KB | fjgarlin |
| #5 | security-but-also-warnings.png | 90.6 KB | bnjmnm |
| #5 | just-security-covered.png | 125.83 KB | bnjmnm |
| #5 | just-warnings.png | 204.87 KB | bnjmnm |
Issue fork project_browser-3294608
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
bnjmnmComment #3
drummUpdating the title to reflect that I think the criteria should be considered after the project cards.
Also - I do think information from these fields should be shown, so this is a replacement.
Server-side, the warnings for things like “Unmaintained” or “No further development” could change at any time. We don’t want to be be in a situation where we are blocking changes to Drupal.org on the core release cycle. Maybe what we really need is a system for Drupal.org to be able to put in arbitrary warnings about a project.
Comment #5
bnjmnmFirst pass of this is an MR now.
If there's security coverage, it's just the icon. There's no longer an "actively maintained" icon.

Borrowing the logic from https://git.drupalcode.org/project/drupalorg/-/blob/e31465608d1380345834... , there are a few different types of warnings worth alerting users about. I'm not sure those three warnings can be intuitively represented by different icons, so in those instances, the presentation is different to allow warning descriptions to be included

In the instances where warnings are present on a module with security coverage, the icon is also accompanied by text just for consistently. It's probably odd to only show the text in this case, but that's what seemed right when I was putting this together. Something a little nicer may get figured out in a few iterations.

Also: it may be worth removing the icons from the filter options entirely since there's only one "good" icon now, and the warnings are applied to multiple criteria. It would also make customizing the styling of those filters easier.
Comment #6
bnjmnmThis may require a few passes before it's good to merge, but it's time to get eyes on it.
Comment #7
tim.plunkettThis should be tagged MVP since it's effectively superseding the other issue.
@fjgarlin, can you review this? I *think* this has some IDs leaking into the front-end that shouldn't, and you might have some good suggestions on how to avoid that.
Comment #8
drummVisually, this looks great so far!
Comment #9
fjgarlin commentedLots of great things. But Tim is right, a few mock-only-related things made it to the front-end that shouldn't, and there is a whole other set of changes that might not be needed as the front-end already has a function to do exactly the same.
I made a few comments in the MR. If you have any questions about it feel free to reach out here or via slack. I'm also happy to help with the code if needed, just tell me.
Comment #10
mmjvb commentedCan the security icon go back to green now?
Comment #11
bnjmnmRE #10
I wouldn't want this issue delayed by trying to reach agreement about that change, but I think there are benefits to making that specific iconography match D.O.
I'd recommend filing a separate issue for the security icon so that discussion is contained. That way neither change blocks the other. It can't hurt to reference this issue and point out the use of the D.O. security icons works well.
Comment #12
fjgarlin commentedComment #13
fjgarlin commentedActually, you didn't set it to NR, so maybe I started testing too soon. I'll wait for this to be marked as NR.
Comment #14
fjgarlin commentedComment #15
fjgarlin commentedThere is some minor feedback from @timplunkett, which once addressed, I think we can set this as RTBC.
I checked the code and I like how clean and readable the new changes are, also addressing front-end and back-end / plugin logic in the right places.
Styling wise it also looks good in my opinion. New cards looking like this:

Comment #16
bnjmnmI filed #3296263: Consider switching security coverage icon to something similar to D.O. to make sure the feedback in #10 regarding the security icon has a place to be discussed, even if it isn't in this specific issue.
Comment #17
fjgarlin commentedBased on #15 and the amends made, marking this as RTBC.
Also, thanks for the follow up issue.
Comment #19
tim.plunkettThis feels really good to have resolved. Thanks @drumm for your patience, and to @bnjmnm for making sure it happened (and @fjgarlin for the reviews!)