Closed (fixed)
Project:
Project Browser
Version:
1.0.x-dev
Component:
Meeting
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
10 Feb 2022 at 06:45 UTC
Updated:
7 Mar 2022 at 02:59 UTC
Jump to comment: Most recent
Welcome to today’s asynchronous Project Browser Site Builder subcommittee meeting! We meet here every Tuesday at 8:00PM UTC (4:00PM ET) I will be starting threads with items that we would like feedback on. If you have something you would like to discuss, please add another thread. Please respond to this thread so we know who attended.
| AmyJune (volkswagenchick) | Hola! AmyJune here. Dialing in from Northern Ca, USA |
| dww | Hi! Derek. Very interested in project browser. Wrote update manager for core. Used to maintain all the project plumbing on d.o... |
| leslieg | great to have you @dww |
| Andrew Olson (andrewozone he/him) | Hello, checking in from the Chicago 'burbs, USA |
| thejimbirch | Hello hello! |
| tim | Hello |
| shaal | Hello :blob_wave: |
| Mihaela (portulaca/prkos) | Ohai :meow-wave-peek: |
| leslieg | Please check thread 6 - tomorrow’s meeting is cancelled. But work can still continue in the issue queue |
| rkoller | hi |
| yogeshmpawar | Hello :wave: |
| gaurav.kapoor | Hi, Gaurav from Delhi, India. |
| Sasa Jovanovic | Hello all, Sasa here from Serbia :wave: |
| guptahemant | Hi, Hemant from India, Syncing in now |
1️⃣ We had a good discussion at the DrupalCon Europe Contribution event around categories on projects. We did a card sorting exercise which resulted in a wide variety of categories selected for the 10 modules we used as a test case. We need clarity on how to move forward with this. The pad with the discussion can be found at EtherPad (thanks Drutopia for providing):https://pad.drutopia.org/p/Project_Category_Card_Sort (edited)
| AmyJune (volkswagenchick) | Do the different colours in the doc just represent who typed what? |
| leslieg | Yes, we had a few folks that joined after we did the initial pass so they typed their thoughts directly into the etherpad |
| leslieg | @dww We are looking at ways to improve module categorization based on some data analysis that @Andrew Olson (andrewozone he/him) and team did on the current projects. Some have as many as 50 categories selected, over 20,000 have no categories. Even very popular modules like Pathauto are not assigned to a category. If one of the filters to the new project browser is to be category, then cleaning up the data seems to be the first step. Of the 54 categories - which to remove as no longer needed, which to rename, combine, add???? |
| leslieg | Link to a spreadsheet with initial thought son the categories can be found at this issue #3240313: Decide on re-categorization of modules for Drupal.org. Do you have any initial thoughts on this? |
| dww | Righto. Hard problem. Given that many modules still haven't had a 1 line fix to be D9 compatible, there's clearly a huge # of projects without active maintainers. But, if there's no maintainer to classify the thing, folks probably shouldn't be adding it to their site. ;) So I don't know that we have to necessarily worry about 20K without categories. The goal shouldn't be to expose everything in the project browser. We should be exposing things of sufficient quality that folks might actually want to use them.... |
| dww | That said, I'm sure there are some items of quality in that 20K unclassified projects, so we can try to do something. |
| leslieg | Agree on that. We were going to start with the most frequently installed modules. The first column in the doc is sorted by that metric. (edited) |
| dww | I believe at some point we're going to want a project maintainer newsletter to go out about this initiative. That letter can include a list of "if you want your project to appear in the browser, here are the criteria the project must meet...". Certainly that list can include "and you need to add reasonable categories to the project so folks can filter and find it..." (more or less). |
| Andrew Olson (andrewozone he/him) | I just quickly read through the notes and that was a fascinating exercise! Well done and disappointed that I missed it. |
| dww | I'm sorry, I'm new here. I'm probably saying a bunch of crap y'all have already discussed / decided. ;) |
| leslieg | We haven’t decided anything yet @dww and would love your input |
| leslieg | the initial prototype for the project_browser contrib module can be found at https://www.drupal.org/project/project_browser |
| leslieg | @dww Thanks for your thoughts on a way to reach maintainers. We wanted to get a few action items for them (categorization, adding a short description for the initial card view with a target audience of site builders and those new to Drupal), etc. We don’t want to go back to them too many times with requests but also don’t want to wait until we get all the asks figured out. |
| dww | I think at least 2 notifications is totally reasonable:"Hi maintainers! We're adding a project browser. Here's what's in the works. If you want to be an alpha tester for this, you can do X, Y and Z. If you have thoughts on the process, join us at A, B, and/or C..."(a few months later). "Hi again! Project browser is getting closer to reality. Thanks to all the alpha testers who contributed so far! Things have evolved, so now you can also do U, V or W, in addition to the X, Y and Z that are still really important..." |
| leslieg | I like that idea. I’ll create a draft and add to an issue for feedback before we send it out. What is the best way to reach maintainers. Does the DA have a list @hestenet (he/him) or is that typically done through the Maintainers channel on slack? |
| hestenet (he/him) | For early discovery/input on in-progress/experimental work, just the Maintainers channel on slack |
| hestenet (he/him) | When we're announcing significant changes to how maintainership works or something like 'hey the browser will go live and you need to do X,Y,Z for your module to look good' we can pull a list and do a send through mailchimp |
| Mihaela (portulaca/prkos) | Is this list cleanup strictly for the current categorization? My suggestions might change depending on whether we have the two different categorizations as we mentioned before, the inside-Drupal we're trying to clean up, and the outside-Drupal that should rely on understanding websites in general. The direction was decided to satisfy the "outside" audience. So far we've only done the "inside" sorting. Correct me if I'm wrong, I'm likely outside the loop.For example: SEO category fits the Pathauto module when you're looking from the outside, you definitely need it, alongside Redirect or similar, for your SEO. But if you look more closely, from the inside, the functionality isn't related to SEO directly (it does nothing to tamper with search result ranking, as an inexperienced person might think, those results only come as a consequence). Maybe there isn't any module that would satisfy that condition, because there isn't a magic wand that makes your website shoot through the ranking, and so maybe having SEO as an inside category doesn't make sense.Shouldn't we work on the two categorizations in parallel? |
| leslieg | We actually discussed that during the Contribution event last week. Being a site builder, I chose Media category for Lightbox2 where the developers in the group chose things like Content Display, theme enhancements, utility, 3rd party integration, etc. Is that a use case filter though, instead of category? Thoughts from others ??? |
| rkoller | the two card sorts at the contrib day were a good exercise to get an idea how different perspectives and mental models of participants are. in regards of moving forward if a content audit reviewing modules has already taken place a good idea might be something like a governance document or some sort of plan in regards of purpose, users, the content, the scope and resources. to get an alignment and idea how to proceed in regards of categories. |
| Mihaela (portulaca/prkos) | That makes perfect sense to me, both angles, the Media makes sense to an outside person, while all the categories developers suggested make sense from the inside. This just confirms you can't have "inside" people decide on what the "outside" people should see unless they can adjust their point of view. |
| guptahemant | As a step to move forward i would like to propose following plan:Lock in on categories which should definitely be removed, like organic groups which should clearly part of the ecosystem.Define what category should define outside view or inside drupal view.My take on this is that it should reflect it both since we do want this as metadata for project browser but we should not forget that developers are still consumers of this data.Also for the outside view, how much drupal knowledge we expect a person might have gained to work with drupal, For ex: After installation would a person be familiar with basic terminology like content types, fields etc, Describing this can help move things forward.Divide the remaining categories in two groups maybe, functional (generic outside Drupal), Inside drupal representation,Get opinions from a wider audience to see how it fits their needs (module maintainers and outside audience alike).(Most important) This is a complex part and we might not get it right at the first go, but there should be a proper way to request for new categories in the system, like using drupal issue queues. In that way if something is missed it can later be extended upon.Some of these points might already be covered, just putting out thoughts which i feel can help us move further :slightly_smiling_face: (edited) |
| rkoller | one point i forgot to ask. are there any search logs available? and in case they are, has there already been an audit and analysis (and are the results available to take a look at somewhere)? otherwise if available but not audit and analysed yet that step might provide some value insight how to proceed. |
| rkoller | @Andrew Olson (andrewozone he/him) pointed me into the right direction. in case for others interested as well a sample search log was linked here: https://drupal.slack.com/archives/C01UHB4QG12/p1628097388015600 |
2️⃣ We need to find another avenue to do the 1-1 listening sessions with folks new to Drupal and site builders. Those folks did not attend the BoF or Contribution event at DrupalCon Europe.
| AmyJune (volkswagenchick) | Tap Discover Drupal students? |
| AmyJune (volkswagenchick) | bribe them with d.o credits? |
| leslieg | Yes, I have that on my list and we will give credit. What are your thoughts on the participants of the DrupalEasy training? Are they at a good point to be interviewed? |
| AmyJune (volkswagenchick) | I think so, we have installed modules and researched them, and many found evaluating them hard… |
| leslieg | perfect, what’s the best way to reach them. Should I ask Mike for email addresses or is there a better way? |
| tim | What about the #support channel? |
| leslieg | Good idea @tim Perhaps we should do a few targeted groups before we open it up to a wider audience. |
| AmyJune (volkswagenchick) | @leslieg let me ask Mike |
| leslieg | Thanks @AmyJune (volkswagenchick) I can do the interviews. If others want to do some, please reach out |
| AmyJune (volkswagenchick) | Ok - i just did an @ here in the current DE slack space |
| AmyJune (volkswagenchick) | what is the best way for me to relay email of those interested in participating in the sessions? |
| AmyJune (volkswagenchick) | Oh!! I’ll cross post in the Discover Drupal space as well |
| leslieg | I’ll create a meta issue and then we can add issues for each interview (listening session) that takes place |
| Mihaela (portulaca/prkos) | Can anyone listen in? I'd love to be a fly on the wall if it doesn't conflict with my schedule |
| leslieg | As long as the participant is ok with it, I think having someone listen in to a few interviews and then go out and do interviews themselves would seem like a good idea |
| rkoller | in regards of listening sessions it is a good idea not to go directly into the listening session. usually you talk upfront with the potential participant .since listening sessions are no questions and answer conversations it is useful on one hand that people volunteering to participate roughly know the topic upfront and that they are talkative. some people are more into yes and no answers or brief answers which is totally fine but that way things stay on the surface level with explanations, preference, opinions and so forth. but instead you try to get to the deeper level getting to know the participants inner thinking, their emotional reactions and their guiding principles aka thinking styles. and an idea to get participants might be asking meet up organizers. they know who are regulars working mainly in the field of site building as well as who is new or still on a novice level. and the positive side effect would be the meet up organizers already know if the persons in consideration are open and talkative. (edited) |
| Mihaela (portulaca/prkos) | I don't mind interviewing, although I see that as more time-intense and I'm not sure how many hours I'd need to prepare for something like that. With listening in I was thinking of just tagging along with a pair of interviewer-interviewee and observe. |
3️⃣ For the UX team to update the designs, we need to make decisions on which fields to include in card (teaser) view. Discussion happening on issue #3240318: Streamline "teaser" (card) view of projects
| Mihaela (portulaca/prkos) | I tried to make a comment there but ended up making a fork? I have no idea how that happened :flushed: |
| leslieg | We’ll take a look |
4️⃣ For folks new to this initiative, Matthew’s prototype can be found at https://www.drupal.org/project/project_browser
| yogeshmpawar | Thank you so much |
7️⃣ Another filter we discussed briefly at the contribution event was “Use case”. What is the user trying to add to their website? This would pull modules from across categories. Example - I want a Publishing website, I want a storefront, …. The thought was to integrate Case Studies here. Maybe have contributors create specific lists of modules needed to add a specific type of functionality. Any thought on that?
| thejimbirch | I like this idea. I feel this would be similar to Fox Valley's idea of Recipes. |
| leslieg | Yes, that was mentioned during our discussion |
| dww | For some things, this could work. But what "use case" do you put token.module in? Or pathauto? Or ... ? |
| dww | For that matter, even something more specific like modules to help deal with date fields... not all date fields are for event registration sites. ;) |
| dww | Some date fields are for publishing. Some date fields are for tagging music you released. Some date fields are for events. ... |
| thejimbirch | Pathauto would be in an SEO recipe. It would require Token. |
| dww | Also seems to muddy the waters a bit with categories. Folks already have trouble classifying projects by category. I could imagine similar trouble with trying to tag by use case, confusion over the difference, etc. Perhaps a better use of time to focus on categories and helping folks get that right. |
| thejimbirch | I don't think every module would be in this "filter". |
| leslieg | We also tossed around the idea of a filter that returns modules that are not core but are added to most websites (pathauto being a good example). So not use case specific for this list |
| dww | I use pathauto on internal sites that don't care about SEO at all. SEO is not the only reason to use pathauto. For that matter, SEO isn't exactly a "use case". That'd be like saying "accessibility is a use case". |
| thejimbirch | I agree. This feels more like another view. A view that lists lists of modules. |
| tim | If I am on the same page, or maybe this is just my thoughts, some modules like pathauto, ctools etc wouldn't specifically fit a use case. Too broad. |
| tim | Assign tags to modules for use cases and categories. Have the UI filter and sortable based on users interests or eventually let the user enable 'recommend ' feature after that is enabled. The recommended would look at current installation. (Just let the user turn recommend off or have separate tab) |
| Mihaela (portulaca/prkos) | @dww a lot of confusion about categorization comes from choosing which audience to target. Current categories were done from the "inside" point of view. The Project Browser initiative was decided to target people outside of Drupal community, who install Drupal through a host one-button script and then want to add functionality to their sites. They need wording/categorization that is free from Drupalisms and techy buzz words. |
| guptahemant | Drupal.org has case studies, I believe case studies can have fields to specify modules being used to build that data, Output from that can become the input for the use cases filter, This way it can provide a curated and a well maintained proven way of implementing something,Also i think it takes off work from the maintainers to tell in which scenarios there module can be used.Sometimes a single module can be used in multiple scenarios. (edited) |
Participants:
AmyJune (volkswagenchick), dww, leslieg, Andrew Olson (andrewozone he/him), thejimbirch, tim, shaal, Mihaela (portulaca/prkos), rkoller, yogeshmpawar, gaurav.kapoor, Sasa Jovanovic, guptahemant, hestenet
Comments
Comment #2
NadiaFaucon commentedComment #3
volkswagenchickThis is a duplicate issue as per reporter:
Comment #4
volkswagenchickCLosed wrong issue. Correcting and closing the right one.
Comment #15
leslieg commentedComment #17
leslieg commentedComment #19
leslieg commentedComment #20
leslieg commented