Closed (fixed)
Project:
Project Browser
Version:
1.0.x-dev
Component:
Drupal.org changes
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
1 Oct 2021 at 17:54 UTC
Updated:
14 Sep 2023 at 15:19 UTC
Jump to comment: Most recent
Comments
Comment #2
chrisfromredfinCurrent work-in-progress spreadsheet for categorization exam:
https://docs.google.com/spreadsheets/d/1igNmyQLybkRhK8x40Gjo1lK8DRaDoGcg...
Comment #3
grienauerabout category/tag discussions we currently had also in a meeting. I would have another proposal:
We could do it with machine-learning…
here are 2 options and a suggestion
As 1) There are some modern keyword extractor models that can be used out-of-the-box (e.g. YAKE and KeyBERT). Disadvantage: good tags rarely appear literally in the description. The best approach I found is described here: https://jaketae.github.io/study/keyword-extraction/
You can play around with YAKE for example here: http://yake.inesctec.pt/demo/user they also have an API
Ad 2) if you develop a clever list of tags, you can get quite far with zero-shot classification (that means you don’t have to label the data individually beforehand). With some labelled training data, however, the thing gets better and you can do good-old supervised learning.
Disadvantage: you can’t handle new labels.
how it could work:
1. we need all descriptions also in that sheets
2. we have to agree to a list of categories (OR at least tags to expand the search possibilities. could be lots of tags)
3. and some peeps categorise/tag a bunch of elements correctly
then we could just use a good old supervised learning on it :)
There have been also some comments on my slack post already:
https://drupal.slack.com/archives/C01UHB4QG12/p1633677153459400
TLDR: others suggested, to look at the code of a module to get from that the categories.
Comment #4
mandclu commentedAs someone who maintains a number of modules (a few of which I adopted) I'd be happy to participate in the discussions around changing the categories. In a different thread, I also suggested that we might also consider more than one vocabulary moving forward, which also allows for more options. For example, if we had separate vocabularies for the functionality provided and the type of module, modules could be allowed a maximum of two each.
We could develop a mapping for existing categories into the new ones. In terms of how to handle the situations where a module might currently have more terms applied than would be allowed moving forward, I would suggest two courses of action:
1. Communicate the change to module owners and encourage them to self-assign to the new vocabularies
2. For modules that don't manually self-assign into the new categories, develop a "ranked" list of the new categories, based on the popularity of the equivalent terms in the existing structure. As a "good faith" approach to an automated migration, migrate to the highest popularity terms first, up to the maximum allowed under the new structure
Comment #5
chrisfromredfinComment #6
chrisfromredfinj/k this issue itself isn't Novice; but we need Novice help with these decisions. :)
Comment #7
tim.plunkettOne note: while we can't (or shouldn't) recategorize modules from within the code, we can opt to not show existing categories like CCK in the meantime.
A small issue to hide certain categories + #3274577: Not all Categories are listed on admin/modules/browse page should be enough.
Comment #8
chrisfromredfinCross-posting this with the BoF where more of this discussion is happening, but a friend of mine who does data science and machine learning help me set up a Bag of Words keyword extractor to do clustering against the descriptions of about 7300 Drupal modules compatible with Drupal 9.5+ - this led me to the following clusters of keywords. I set it up to target 20 categories, but it can easily be tweaked. We might use this to cross-check the lists we came up with:
Cluster 0: user login users password email account site role page admin
Cluster 1: field formatter type fields widget text link values display new
Cluster 2: time date field range content events picker datetime set site
Cluster 3: view mode content modes display entity user permissions select admin
Cluster 4: site use content api modules configuration users integration simple using
Cluster 5: taxonomy terms term vocabulary reference content nodes vocabularies import hierarchy
Cluster 6: group groups permissions content members requirements extends based associate create
Cluster 7: entity reference field entities content type fields form create types
Cluster 8: search api solr index backend engine autocomplete functionality indexing views
Cluster 9: language switcher links languages content set different ip negotiation settings
Cluster 10: commerce payment gateway integrates checkout payments integration product order shipping
Cluster 11: views filter plugin style view display filters adds fields page
Cluster 12: consider ukraine fight freedom safety supporting ukrainian europe maintained developers
Cluster 13: data api json database source export external site content storage
Cluster 14: node content nodes type edit page add entity adds pages
Cluster 15: cache tags events time blocks clear purge settings new tag
Cluster 16: media entity file entities library core image files source embed
Cluster 17: block blocks layout display add content page site builder using
Cluster 18: image images style field formatter styles responsive file background optimize
Cluster 19: video embed videos field url youtube handler add support pasting
Comment #9
bsnodgrass commentedInteresting approach... While taking a pass through the resulting list on https://www.drupal.org/project/project_browser/issues/3311475, my purely subjective opinion is the is feels pretty complete, while certainly being shorter than the current number of categories.
Comment #10
rkollerI've added #3314350: [meta] Usability improvements for Project Browser only as related issue since it was already linked to the google data studio parent issue.
Comment #11
rkollerComment #12
bsnodgrass commentedFinally finished my pass at this. https://docs.google.com/document/d/1PO24Bkd34Hd0yZB75ZN2DrpA-sBOOWTzQOZc...
Sorry I think I was supposed to add this to the child issue.
Comment #13
benjifisher@rkoller and I discussed the current categories during #3326232: Drupal Usability Meeting 2022-12-16. That issue has a link to the recording of our discussion. We plan to return to the question in an upcoming Usability meeting, when the list is closer to its final form.
Since there were only two of us, these suggestions should not be considered recommendations of the usability group, just ideas to consider:
Comment #16
chrisfromredfinWe still have some user testing to do at DrupalCon Pittsburgh around these, but this is the current draft of 19 categories that we've come up with.
Comment #17
chrisfromredfinClosing as this work has moved to https://www.drupal.org/project/project_browser/issues/3382689