Project Browser Initiative meeting for September 8, 2021 new

Update from Site Builder Subcommittee:

AmyJune started looking at a skeleton template for the project page descriptions.

UX folks were present at the meeting so most of the discussion was about the designs and the templates they made. They did a lot of market research with other communities. Would be worthwhile to maybe bring in some WordPress folks or other people that have marketplaces. We have some Drupal people we know, AmyJune knows some WordPress people, and Jillian also knows some folks.

Jillian - the idea of doing listening groups and reaching out to anyone who's building websites to see what current practices are. Especially around libraries/browsers/marketplaces. We want to answer some of the questions we have around problems we're trying to solve. Looking at WP was a good place, because they have that plugin/library that people can pull from. Want to get an idea of how they use it now, and also if there are some challenges they face with their current marketplace. How are we going to organize and make these modules easily findable. Especially for new Drupalists.

Leslie: The next step is then the framework for these listening sessions. We want some consistency with how we approach people.

Jillian - we've done some research on our end about what a digital experience marketplace looks like. Talked to a lot of IT people and marketing people some who are and who aren't using them. What do people value out of a marketplace organization/setup? Currently analyzing that data and hopefully that's useful to us here. Also sent a list of question over to Andrew (Olson?) toi get people talking about what problems they're having. Want to find solutions to THOSE problems.

Andrew - the questions are really great. I shared the ones we had for Design4Drupal. We didn't get to the format there, but they are good questions. I can share those someplace, but what would be great is having that consistent listening session approach. If it's too scattered then it might eb hard to pull it all together. Next meeting we'll go through the questions and see what we think a listening session should be like. Maybe we can tack on to DrupalCon Europe or other sessions.

Great time to do listening sessions is DCon Europe.

AmyJune - hoped to have more done, but started with a blank page. I did throw a bunch of sttuff on a blank page. Not blank any more, but it's a bunch of stuff to look at to help ideate and formulate. Two questions tho: (1) do we want to have the project page re-worked into fields, or (2) have a template inserted into the body field?

Neil - the second one is much better. What's left is we have some fields and we need to implement some definitions and tooltips around "Component" and "ecosystem" - right now with the existing fields we have some description but it's not great. We're going to write up some more. Will take a couple example pages and write them up. Intuitive and not a lot of fluff.

Andrew is still looking at analyzing some of the data. Want to look at categories and see if they're useful/appropriate. Tooltips on project page or documentation or something, we really want to help people choose correctly.

== updates to design? nothing specific. But we talked about having two layouts (cards and list), talked about not having images for all of these, module page itself. What would it look like if we did reviews. figma design link in slack channel.

== meeting

Should we shift to Slack meetings, except like once a month?
> Tim uses that format on other initiatives and it works well for them. Most other initiatives are using that format. There's also a browser extension for Chrome so that that threaded format can be posted to an issue. It works really well. For this particular TOPIC we need a Zoom call, then we add it in as needed. It's helpful and more inclusive for people in different timezones.

> tim says "let's try it" there's some advantages. Make sure we do Zoom if needed.

> Makes my job easier as chief note-taker.

== update for Slack thread

he does have an endpoint that's working with some data. now the question is where does that get hosted. We'll need to have some infrastructure in place, dealing with that with Association. Next steps looks like find a way to get the migrated data into a production hosted environment. Also how do we keep it refreshed?

> Chris, Matt will do a demo this afternoon, will be recorded.

> Rajab - replying to Chris direction, let's switch to issues & Slakc. It's easier and faster. Comments about hte designs, they really look nice and we do feel easygoing when you browse them. I like the two directions, one more with search, and one with category/browing. It's easier/different behavior when we browse the projects.

Want to talk about the filtering criteria. Anything we add on the project page, the one AmyJune is working on, any filtering criteria should be used in the advanced filtering. This it he main point of that, a basic filter could make people's life easier. For example Neil was talking about projects and why they're not and it really switched the behavior. Filtering is clutch.

> update from MAtt. G.

Migration is done enough to get started. Hopefully this stuff is useful for DA for doing the complete migration. It was helpful to work with Wim on core stuff. I'm gonna push it up to a hosted environment and share it.

Gonna try and see if I can get a free Acquia subscription for the initiative. Then everyone can get their own dev/stage/IDE environment. Then it makes it easy to share.

In terms of actual work:
> refactoring queries to use the new production server
> refactor the frontend so it starts to look closer to jillian's mockups.
- good first step is training.
... this is an OK solution for now for doing the development. And then that gives Association people a good opportunity.

Matt Grasmick will be the spearhead on that Acquia setup. We can add an Acquia section to the README. @TODO Matt will set up Acquia dev env.

Is there still user data in there? It should be scrubbed of PII, but who knows. @TODO Neil & Tim will decide on Drupal Contributor Agreement stuff if we need it. Neil's pretty happy but we're getting close to freely sharing it which we don't want to do.

For MidCamp, we had everyone link to the CoC and then they had to sign their name in the issue. It gave credit and kept track of people.

Neil -
fields and things. As far as adding fields to projects, some of the reasons I tend to prefer doing it more with templating within the body is that field changes on Drupal.org are a little hard to deploy. Clearing field caches causes a small outage. We'll take the outage as necessary. But if we change ecosystem or something major, that's off the table. The module in core will need some "defensive programming" to be able to handle what happens if ecosystem legit disappears, ex.g. The module should be robust so that we can maintain d.o independently of Drupal's release cycle. Also it will take time for things to be utilized. Like we see wiht stars, they've been around 2 years. Also if we add reviews, it's going to be a while before they're useful.

Tim: that suggests to me that we might need a deprecation and addition strategy for the change management / continued iterations of this feature. There's no SLA about the API currently, ex.g. and we like it that way.