Limit number of "Categories" on the Drupal.org Project page

I think some thought will need to be given to the UI for selecting categories. I would suggest avoiding an autocomplete field, since it requires the user to have some idea what to type, and will likely cause frustration. We could probably use some variation of the current multi-select list, with a limit on the number of values. By default, it lets you select unlimited items, and rejects when you press submit. I think some JS to prevent selection of more than 3 would help users avoid trying to submit more than will be accepted.

I would probably argue that they should be three single-select lists, so that the weight matters. Someday we may consider the first category to be 'primary' or weighted differently (we have discussed at some point), and though that's not currently in the spec, this UI would leave it open to that?

With 🌱 Migrating "Categories" on Drupal.org Project pages Fixed done, the distribution is:

MariaDB [drupal]> SELECT s.c, count(1) FROM (SELECT count(fd_tv3.entity_id) c FROM node n INNER JOIN field_data_field_project_type fdf_pt ON fdf_pt.entity_id = n.nid AND fdf_pt.field_project_type_value = 'full' LEFT JOIN field_data_taxonomy_vocabulary_3 fd_tv3 ON fd_tv3.entity_id = n.nid WHERE n.status = 1 AND n.type = 'project_module' GROUP BY n.nid ORDER BY NULL) s GROUP BY s.c;
+----+----------+
| c  | count(1) |
+----+----------+
|  0 |     4977 |
|  1 |    14199 |
|  2 |     8442 |
|  3 |     4120 |
|  4 |     1552 |
|  5 |      465 |
|  6 |      160 |
|  7 |       42 |
|  8 |        9 |
|  9 |        1 |
| 10 |        2 |
| 11 |        3 |
| 12 |        1 |
| 13 |        1 |
| 18 |        1 |
| 19 |        2 |
+----+----------+

93% of modules, excluding sandboxes, have 3 or fewer categories.

I think we should have some allowance for projects with 4, maybe 5 or 6, categories to remain as-is. Once this issue is fixed, they will have to pare down their own categories when they next update their project. We wouldn't be able to make good bulk decisions to remove the extra categories. And I think the data loss from resetting them to having no categories would not be helpful overall.

The ones with 7 or 8 or more categories can be reset to none, since those are clearly outliers with less-meaningful selections.

Awesome stuff. Allowing modules with 4-6 categories to keep them until they next update their module page, then forcing them to reduce to 3 would seem a good compromise.

Can the maintainers of the modules getting their categories reset be notified?

Also, I can't speak for the other 4976 modules with no categories, but I have a new module, and I decided there was no point in assigning it to categories until the new ones were implemented.

Since we’re already communicating with project maintainers a lot with separate issues for their description, logo, and potentially categories now, I’m hesitant to make more work for project maintainers.

Like we did for the category migrations, the revisions of the project page will have the URL to this issue for an explanation.

Since its always good to have specifics, here are the module with 7 or more categories:

7 Open Y Google Translate →
7 DXPR Builder | Drupal Page Builder | Bootstrap Layout Builder →
7 Watchdog Event Extras →
7 Query-Based Views (Q-Views) →
7 Entity Schedule Sync →
7 Facebook-style Links →
7 Service links →
7 org →
7 mailflatrate for drupal 8 →
7 Dsi center →
7 File uploader by Uppy →
7 Support Ukraine →
7 Splitting.js →
7 SMSC →
7 Role Based Views Entity Reference →
7 E-MAILiT Sharing Buttons →
7 Web Service Client Manager →
7 TotalFlow →
7 Commerce clone product variation →
7 JW Platform Media Source →
7 CMP Sirdata →
7 COOKiES Services →
7 Contextual Administration →
7 Website Toolbar →
7 Convert URL Filter →
7 Type User Nids →
7 Featured Content →
7 Communities →
7 DubBot →
7 Icomoon →
7 Kill Adblock →
7 COOKiES Media Entity Facebook →
7 Update Me →
7 Excluded →
7 Encrypted Text →
7 POWr Form Builder →
7 Nodelocks →
7 Super Nav →
7 File uploader →
7 Resize Text →
7 Google Picker →
7 Variants →
8 Intelligent Content Tools →
8 Marketing Automation →
8 Hiberus tools →
8 AddToAny Share Buttons →
8 CiviCRM Entity →
8 Ajax Table →
8 shortlink →
8 Import Export →
8 Embed Import →
9 Apture →
10 Headup Complementary Content Widget →
10 Persian Date for Drupal 8 →
11 Social Sharing, Follow Bar & Share Buttons by GetSocial.io →
11 OSF for Drupal →
11 Wibiya →
12 changedetection.io →
13 Share Buttons, Related Posts, Content Analytics - Shareaholic →
18 Drupal Extra →
19 Test Drupal 2021 →
19 Textimate →

If any already have description update requests, I’d recommend adding recommended categories to that issue.

While we are on Drupal 7, we should keep changes minimal. Setting the field’s cardinality to 3 works well.

When we’ve upgraded, we can look at other field widgets. Maybe as simple as using the checkboxes widget, altering in the category descriptions, and putting it in a scrollable container.

I can’t think of how a primary category would practically show up in search indexing. We could have a boost for a primary category matching the category search filter; but I think the project usage, full text search matches, and other project quality boosts would be larger, making a primary category match less likely to change result ordering. And this keeps the widget, and explanation for the module maintainer, more straightforward.

Since this is a field configuration update, we should set the description at the same time, linking to the page being created at 📌 Create a "Categories" Help page on Drupal.org Active . Something like:

Review category descriptions → , select up to 3.

This is now deployed. The only remaining task is to clear categories from modules which selected too many.

Modules with 7 or more categories have been reset to have no categories.

Automatically closed - issue fixed for 2 weeks with no activity.