Consider removing the development status filter

After some discussion with @chrisfromredfin, @fjgarlin, and @drumm, I think this is probably a bigger issue that should be postponed and rescoped.

@drumm made the point that, on drupal.org, "actively developed" is a "neutral" status. One does not say "this module is actively developed!" -- it simply refers to any module that has not been explicitly marked as minimally maintained, obsolete, insecure, or some other "negative" status.

To me, this suggests that Project Browser's IA could be simplified, such that we remove the development status filter while at the same time changing the "actively maintained" filter to instead -- internally -- be a filter that equates to "not obsolete, and not minimally maintained, and not insecure, etc."

But that does not need to block anything. The frontend is internal, and what filters sources define is also completely up to them.

Right now we have the endpoint https://www.drupal.org/drupalorg-api/project-browser-filters → , which returns:

{
    "active": [
        "e767288c-9800-4fb4-aeb8-8c311533838a",
        "219c1cf2-dd7f-474b-9dd5-a26643fbc699"
    ],
    "maintained": [
        "089406ad-304d-4737-80d1-2f08527ae49e",
        "cee844e2-68b5-489d-bafa-6a0ade2b6dfd",
        "09a378d2-fd35-41f3-bff0-10d9801741a4"
    ]
}

We can expand to return: inactive and unmaintained. The current logic for that endpoint's output is here: https://git.drupalcode.org/project/drupalorg/-/blob/1.0.x/src/Controller...

https://www.drupal.org/drupalorg-api/project-browser-filters → now returns:

{
    "active": [
        "e767288c-9800-4fb4-aeb8-8c311533838a",
        "219c1cf2-dd7f-474b-9dd5-a26643fbc699"
    ],
    "maintained": [
        "089406ad-304d-4737-80d1-2f08527ae49e",
        "cee844e2-68b5-489d-bafa-6a0ade2b6dfd",
        "09a378d2-fd35-41f3-bff0-10d9801741a4"
    ],
    "not-active": [
        "0e260036-be60-4f88-9aa5-f9db2eee678a",
        "f42e375f-de53-40fc-ad5e-25c422b05fa7"
    ],
    "not-maintained": [
        "da38f99c-5b5a-41f6-99ce-7a78cc0e8396",
        "01beb22a-d9b2-4fa7-9497-e480a6706680"
    ]
}

So this issue can continue (and the fixtures will need regenerating as part of this: https://git.drupalcode.org/project/project_browser#updating-fixtures-for...)

Fixing the tests is gonna take some doing, since this is a definite logic change and will alter the number of projects that come up, and which projects come up, in any given search.

Copying my thoughts from previous Slack conversations:

My personal opinion is that a lot of projects has maintenance and development status misconfigured, so it does not add much value for users. If that status would reflect for example commits, or issues activity, then it can be probably beneficial. But currently even some abandoned module can set these to "active development" without any implications. I raised this concern earlier in https://www.drupal.org/project/project_browser/issues/3267678#comment-15... 📌 Replace Wrench icon on project views with Gear icon Postponed . So I am all in favour for removing the filter.

To me, this suggests that Project Browser's IA could be simplified, such that we remove the development status filter while at the same time changing the "actively maintained" filter to instead -- internally -- be a filter that equates to "not obsolete, and not minimally maintained, and not insecure, etc."

As long as we’re not completely blocking access to browse all modules, this looks good to me. We can rank obsolete/unmaintained/etc projects lower, show clear warnings, and initially hide them, but I think we do want to keep them accessible. For example, if you remember a module exists, it should be discoverable that it went unmaintained. Regardless, these filters don’t need to take up screen real estate in project browser.

We can double check this server-side - minimally maintained is not a negative status. If something is stable and/or straightforward, it doesn’t need more than minimal maintenance, and that’s good for the project.

Another even simpler option would be to not show the filter at all, anywhere, but just render the "negative" icons in the project card and detail page. This might be more drastic but probably none of the top modules will "show" those icons so it's not like we are going to be flooded with bad projects.

I left some minor feedback in the MR. We''d probably need to alter the queries here https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/tests/mo... to match the actual queries being made. Note that this cannot be automated in the regeneration script as that is actually the source used to rerun the queries.

Another even simpler option would be to not show the filter at all, anywhere, but just render the "negative" icons in the project card and detail page. This might be more drastic but probably none of the top modules will "show" those icons so it's not like we are going to be flooded with bad projects.

Big +1 to this. If there’s concern people will see “bad” projects, we can rank them lower server-side. We should probably do that rank adjustment regardless.

I spoke with quite a few module maintainers at DrupalCon Atlanta and received almost unanimous feedback that they do update both the Maintenance Status and Development Status fields on the Drupal.org project pages. They feel that both have value to the project ecosystem.

In terms of what to show in Project Browser, they agree that the development status should not be displayed as a filter, since it is not important to the target audience. However, they do feel that having the filter as an "Advanced filter" is helpful to more advanced users who may be looking for specific levels of development status. And maintenance status as well.

Adding a link to Advanced filtering was something we originally had on Project Browser and something we should consider adding back. Note - we originally didn't have maintenance status or development status as available filters, but instead defaulted to maintained projects. And wanted to add help text that explained that by default, users were viewing modules covered by the secutity policy that were actively maintained and work with the site's Drupal version. (text was not exactly like this)