Project Browser Meeting for November 10, 2021 [#3250225]

@shaal what's the right thing here? #3248299: Requirements not specified in composer.json#comment-14287211

shaal	do you have a moment to discuss this?
chrisfromredfin	yes, or we can hit it up during the normal meeting which is in 20 minutes :slightly_smiling_face:
shaal	sure, we can do that too
shaal	I can confirm there is a problem
chrisfromredfin	ok cool I have my standup and I'll add a thread to meeting for this.
shaal	I've seen something similar before, and the solution should be that the module's composer.json should include all dependencies required (info.yml not helpful here)
shaal	I wonder WHY do we even have that info in info.yml, instead of pulling it from composer.json
chrisfromredfin	My initial thought was that it should be in composer.json too as it's currently contrib afaik
thejimbirch	If a site builder downloads a module, and tries to install it, Drupal needs to know about the dependencies also.
timplunkett (he/him)	composer.json is what to download, info.yml is what to install
timplunkett (he/him)	#1398772: Replace .info.yml with composer.json for extensions is an idea to combine those notions
shaal	This commit #3245770: Create a service to composer install via package_manager from Automatic Updates broke project_browser, when installing it using composer
shaal	If https://www.drupal.org/project/automatic_updates is what's needed, we should install it as additional module.
shaal	When it gets to core - only then project_browser should update the code to core's package_manager (edited)
gaurav.kapoor	I wasn't expecting that WIP MR for the issue #3245770: Create a service to composer install via package_manager from Automatic Updates would be pushed to the main repository :stuck_out_tongue_winking_eye:. I did mention in the comments for now I am just updating dependency in info.yml file as that's how automatic updates is handling the required package manager. Let's composer require automatic updates modules 8.x-2.x branch as a temporary solution.
chrisfromredfin	Agree, let's do that. Also if an MR is WIP then it can be marked as such in the Gitlab UI by starting its description with "Draft: " or "WIP: " and that will prevent merging. :slightly_smiling_face:
gaurav.kapoor	Cool.
gaurav.kapoor	I will update the issue #3248299: Requirements not specified in composer.json and add new MR.
shaal	Thank you!
timplunkett (he/him)	FYI only problem with marking as WIP is that it won't run tests
Rajab Natshah	I would love if Drupal core can change from dependencies: to install: in the in modules, themes. same like profiles (edited)
timplunkett (he/him)	@grasmash did you mean to commit from Active? Not even NR, let alone RTBC
Rajab Natshah	Noticed that install: is used by profiles in the .info.ymlfrom the How to write a Drupal installation profileDid the same but for modules too: Issue #3017554: Changed [Varbase Core] Components dependencies on install: enable or dependencies: enable of modules in the .info.yml and composer.json to have tilde Version Range (~)
Rajab Natshah	Having that fixed so many issues. as composer.json is only getting extensions and the install: in .info.yml is only enabling.installing is easier, uninstalling is easier tooadding and removing is easer too
Rajab Natshah	Also using the tilde Version Range (~) in the composer
shaal	@chrisfromredfin the last comment you added on that main issue wasthe real issue is that our Gitpod link doesn't work to easily spin up and work with the projectWhat doesn't work / not easy? Is there something we can do to make it better?
chrisfromredfin	No I was wondering if the right thing was to put the dependency on composer or to just tell DrupalPod to install the module. But composer sounds like the right thing - else that very easy. Was just noticing with Mikes comment that it didn't work out of the box due to this bug
shaal	:+1:
shaal	I think it comes down to a commit that was merged by mistake, and broke some stuff

2️⃣ I have made some progress on the Drupal 9 site both with gitlab-ci automatically deploying to Acquia from pushes on that repo, and on integrating Search API to start pulling back data about our modules. From the current proposal of "recommended" modules we get about 10000 projects back of about 47000 (~22%). However a lot of those projects are only needed for D7 and below, so I'd like to know how narrow we get for, say, a Drupal 9 site. Also, need to pull in data about releases in order to understand if there is a "recommended" and "supported" release available on the project, in "this version of Drupal" (the version using the Project Browser).

chrisfromredfin	So, if anyone has any insight into how to index that kind of data in Solr (basically need to index a custom field, maybe? computed field? something like that?) let me know. :slightly_smiling_face: I assume there's a search_api hook or something to provide a field?
Rajab Natshah	@chrisfromredfin I had a look at your commits.nice workYesterday I noticed a new release for search_api_solr 4.2.2 9 Nov 2021 by mkalkbrenner (edited)
chrisfromredfin	There are some other things to update on that site, too. Maybe I'll take a swipe at that.
mandclu	Worth pointing out that https://dev.acquia.com/drupal9/deprecation_status lists 7042 modules as being explicitly D9 compatible, so likely this should be the starting number, but if we add some other filters to make them "recommended" (e.g. security coverage, stable release, etc) the number should be lower than that.
Rajab Natshah	Oh, yah @mandclu . This is a reminder to make all custom code compatible with Drupal 10
chrisfromredfin	for sure ^
Rajab Natshah	custom modules for now. And follow up on used contrib modules before D10
Rajab Natshah	I think I find something which I could help in

3️⃣ @timplunkett (he/him) has some availability with a small team to sprint on frontend work November 15-19. I would love to decide on MVP front-end designs and have them ready to go for him to start. this will involve @Jillian Chueka et al, as well as our feedback. Tim if you can remind us of what the order of things are that you're wanting to work on, I'd love to just get group buy-in that that sounds right (I think it does). It was (a) card view and (b) search/filters in the right spot and (c) ____ and (d) the detail page, but I think SBS decided let's totally push that out to Phase 2, so definitely could/should be last. @leslieg can remind us here, or when she provides the SBS update.

timplunkett (he/him)	Filters/search/landing pageCard viewList viewDetail page
chrisfromredfin	Perfect. @Jillian Chueka let us know if we can have an updated figma or subset of figma designs ready in advance of Tim's sprint
Jillian Chueka	https://www.figma.com/file/1Z8xrcP2zgnO6BXlu9ZeQ5/Project-browser?node-i... The designs are here in this file. I’m fixing a few accessibility things but they are ready.
thejimbirch	I commented on the issue in the queue, and yesterday, but will post here for visibility.
thejimbirch	The fonts and buttons seem to have their own styles. This looks Claro-ish, but may use a different font, button styles are different, etc...Since this is destined for core, shouldn't the theming be less opinionated?Would it be possible once the layout/content are decided to have a version using Seven's and a version using Claro's default styles?
thejimbirch	Or will that be taken into account by the dev team?
chrisfromredfin	FYI for @timplunkett (he/him) - probably want to just be sure to inherit as much styling as we can from default admin theme, yes?
timplunkett (he/him)	Yes, when in doubt will not change those styles in CSS and inherit from the admin theme where appropriate
Jillian Chueka	In terms of filters, I do have a few questions. I used the filters I found on Drupal.org and edited a few options out per previous conversations (i.e. sandboxes).What does it mean when a module is “stable”? Are there defined metrics for qualifying this? In terms of design, we used the Drupal design system so that’s why it looks Claro-ish. It still needs to inherit some elements as we focused on functionality first.
chrisfromredfin	"Stable" means it has a 1.0.0 - that is, not -alpha -beta -rc. Note that "has security coverage" implies stability, because security coverage will never be applied except to stable versions
chrisfromredfin	My hunch is we should actually remove the 'stable' filter and let the security coverage speak to those
Jillian Chueka	Gotcha. That was my instinct too and why I asked.
mandclu	So technically, a module can opt into security coverage but this will only apply to stable releases. So for those who want security coverage, the combination is important.
leslieg	The thought from the SBS was that we will not be ready with mockups for the Detail page by the sprint. We would need to decide on using @AmyJune (volkswagenchick she/her)’s template, a better way to display content (fields) consistently across projects, etc. This would need further discussion, a mockup from @Jillian Chueka’s team and a well-defined issue. Thinking is that we could not accomplish all that in time.
mandclu	Also worth pointing out that a module can have different branches, so it's possible to have a branch with a stable release, and a newer one that is not yet stable. I would say that from a site owner's perspective, "stable" should mean that a module has a branch that is both of:compatible with the site's version of Drupalhas a stable release
mandclu	If we are less concerned about "stable" but want "security coverage", then really that should mean both of the above PLUS the module has opted into security coverage

4️⃣ I have volunteered our initiative to be the trial run for Gitlab-Accelerate. That means we MAY be moving all of our issues to Gitlab and handling a lot of testing through gitlab-ci.yml there. There's nothing to do on this yet, but wanted people to be aware that I offered that as a way to help that project & the community. Had a good chat yesterday about DrupalSpoons and I'll be in touch with the GA team and y'all should there be any future announcements. Again, for now, no change.

Rajab Natshah

I'm with that. we all should start using the new way.

5️⃣ Does anyone have any thoughts on #3239865: Front end design review and discussion#comment-14286424 (my comment #9)

6️⃣ @Jillian Chueka has this been done? #3246702: Move Designs to Drupal's Figma Account

leslieg	Yes I believe the new link provided is from the Drupal Figma space. Looking for the comment about this
Jillian Chueka	YES! This has been done.

5️⃣ Update from Site Builder Subcommittee. 1. Possibly replacing the icon to get to the advanced filters (the lines to the right of search) with a button labeled “Advanced Filters”. 2. Differing opinions on the default logo for the card view for modules without a logo. 3. Different states of the button on the card. “Download” if not on the site, “Install” if on the site but not installed and a gray “Installed” button if already installed on the site. Each would go to a set of instructions. We thought Installed could lead to instructions for uninstalling, but the current instructions are too technical. We prefer pointing to d.o pages for each of these, rather than maintaining instructions in multiple places. 4. Will we be using an existing theme (Claro, Seven) to get styles for fonts and buttons

chrisfromredfin	And I would think Claro initially / for MVP as that's the default in D9, right?
chrisfromredfin	or is that not yet true?

8️⃣ @Jillian Chueka @leslieg @timplunkett (he/him) et al - I think we maybe agreed that we still want exposed sort in MVP, right? #3239477: Expose sort options - if so, maybe that belongs back in, above the categories filter?

leslieg	We had talked about “Popularity” being the default sort if no search term was entered and “Relevance” being the default sort if a search term was entered. Besides these two, the other options were alphabetical and possibly last release.
Jillian Chueka	I added the option to sort and the current options I have are: A-Z, Z-A, Author, Newest, Oldest, Sponsored. Whatever makes it easier for the user to find what they are looking for. Up for other options.
Jillian Chueka	I also added Top Modules as an Advanced Search function under Collections
chrisfromredfin	I think Leslie's options are the ones we're most interested in above. See #3239477: Expose sort options
chrisfromredfin	(for MVP anyway)
chrisfromredfin	I also don't understand collections at all.

9️⃣ Once we have have the process cemented in, ie not going to change we need to work with the D.A. And do some marketing to communicate specifically with the developers that their module/project is going to disappear in the new project browser unless certain conditions are meet. We need to give them lots of time to let them do that.If module is not marked stable wont show correct? (edited)

mandclu	I'm happy to bring that discussion to the #maintainers channel when we've decided on the approach
chrisfromredfin	Yes, and I do think that we're not just coming in guns blazing. We also have a plan to offer to help. @leslieg and SBS intends to file issues to help them (a) with a new logo image (b) with updating their descriptions (c) with refining their categories
tim	Yes that would be good. Maybe contribute too?But also thinking an email to maintainers...
tim	Oh good!!
mandclu	Is there a plan to make a new field for the logo, or is the plan to just use the first image attached?
chrisfromredfin	There will definitely be something int he Drupal newsletter or something as we get closer, or a note to maintainers, yes. I wonder if you would file an issue for that Tim in the queue? We can mark it postponed.
chrisfromredfin	@mandclu for MVP we intend to use the first image in the main images field. In future we're hoping it may be a separate field.
tim	Maybe add documentation to that list but that might be a big topic.... Keep it to the critical points??
chrisfromredfin	Hoping @Nico Grienauer (he/him) might step forward and start busting out more logos once we identify the sort of "top 100 modules" that will show up in the default sort
mandclu	Happy to put something in that channel today, unless we'd prefer to wait and refine what we want to communicate
chrisfromredfin	wdym Tim, add documentation to what list?
chrisfromredfin	@mandclu I would wait, I don't think we're close enough to get anyone's hackles up yet :slightly_smiling_face:
leslieg	Agree on waiting a bit. We want to make sure we have a plan first and minimize asks of maintainers while also offering contribution as a way for folks to step in to take a first pass to help maintainers, but allow maintainers to review
tim	Sorry the list that @leslieg has to help maintainers
chrisfromredfin	oh right, yes. that would be a bigger ask, as you say. maybe even a whole sub-initiative :slightly_smiling_face:
Nico Grienauer (he/him)	@chrisfromredfin happy to help when the list is there to create vor the modules issues and also proposals for module logos :)
tim	Lets wait until we are sure not going to change if its official. But could also tell in advance what is likely to happen. and add why.
mandclu	Yes, it would be better to err on the side of communicating more, even if some of the early communication is just to makes sure everyone is aware of these conversations and have an opportunity to voice their opinions
tim	Agree there is a balance -Give as much time as possibleDon't give out bad info (edited)
tim	@chrisfromredfin I guess I should ask for help in creating the issue as you requested. Want to do it right... or @leslieg
tim	@mandclu I want to put some numbers in as a suggestion for how long we should give a developer time to get their project up to speed, How much time would you expect? Give me a high and a low number.
tim	2 weeks isn't enough time right?I don't imagine they would need 6 months notice?(of course there might be some that would need more but need to draw the line ....)
mandclu	@tim I would say it ultimately depends on what changes we want to encourage. For metadata changes (e.g. first image, categories, etc) 2-8 weeks seems reasonable to me. If we're talking about moving them to a stable release, I would say we should allow for longer, as there are projects being used by thousands of sites, with only an alpha release. Typically to move from alpha to stable involves multiple releases, so I would encourage us to allow a minimum of 2 months, with six months at the high end for a formal announcement, but ideally to start getting the word out informally as soon as possible.

Participants:

shaal, chrisfromredfin, thejimbirch, timplunkett (he/him), gaurav.kapoor, Rajab Natshah, mandclu, Jillian Chueka, leslieg, tim, Nico Grienauer (he/him)