Project Browser Initiative meeting for May 27, 2021

High level summary of meeting

Mihaela kicked off the meeting by presenting some research she has done in the past week to help identify personas in the Drupal community that would be served by this Initiative.

She first acknowledged that there is a hurdle to installing contributed modules in Drupal 8, due to Composer, and the four types of personas identified were differentiated along those lines:

1. The "Manual Installer." This persona might be a small site/business owner who manages their one website through FTP, possibly without the use of a staging or dev environment. Generally they would be using shared hosting. While comfortable with tinkering, they can get "module happy" and install many modules, assuming that they all are of the same quality and all work nicely together, which may not be the case.
2. Laid back Drupalers. These people don't mind not being on the cutting edge. Maybe they're a little more technologically advanced than the Manual Installer, but if they're not using composer, they are OK with that. They are probably pretty comfortable with Drupal 7 and are happy to stay there as long as they can.
3. Eager Drupalists. These people know they're not on the cutting edge, but they want to be. They know they're not where they need to be, and may want/need/seek help getting there.
4. Advaced Drupalists. These people are on the cutting edge, using all the best practices for installing and maintaining a Drupal site, including version control, Enterprise hosting, advanced features of Drupal, etc.

When looking at these audiences, they may have different needs, and it's hard to dissociate their needs from the installation methods they're using to install Drupal modules. It may be that for MVP, the Project Browser gives you several instructions for install methods, such as a link to the tar.gz file, a Drush command, and a Composer command. Installing modules is one of the biggest barriers for power-users/site builders. Solving problems like these at the Manual Installer level can still solve problems and make life easier for those at other levels.

People at higher levels might want to see some Drupal-specific information in their browsing/shopping experience, like:

• How many maintainers on the project
• How many outstanding / unresolved issues
• How secure the module is
• How many installs

Open Discussion

After opening the discussion up after presenting these personas, conversation quickly evolved into a discussion around "curation" of modules to be presented by this system. There are some very common use-cases for Drupal that are installed nearly everywhere: projects like Pathauto & Metatag for example. So any algorithm or criteria which recommends modules should take into account popularity. Factors to consider:

• Popularity (downloads)
• Complexity (number of dependencies, etc)
• "Freshness" - last contibuted to or last activity by maintainers in the issue queue, ex.g. This can be complicated by the fact that some modules "just work" and are of high quality, so don't need maintenance or have issues. Other times, referenced libraries are linking from d.o to spam sites.
• Security - we need to ensure bad actors are not let into the featured/promoted/curated tier.

With that said, others expressed the desire to "turn on the fire hose" and just see everything. So, we should consider a flag or way to see all the projects if that is what the "shopper" chooses. Whether this refers them to Drupal.org or turns on more projects inside the Browser is TBD. There are many technical considerations for which is better, which can be delayed until we have defined the MVP.

One side effect of having criteria for "top-tier" modules is our ability to shape how project maintainers may behave. For example, we can require that documentation exist in the Drupal handbook in order to be in the tier.

We spoke about the need to revamp the search functionality of the existing Drupal.org project browser. Sometimes even searching for the module name doesn't pull it up in the initial results. Sometimes we have names like "ctools" that aren't as descriptive of what they are used for or do. There may be some things on drupal.org projects that may need to be changed. We talked about the need for more screenshots on many projects, as well as robust user-friendly descriptions for modules that are written for the global audience and not developers.

By the end of the project, we were mostly in agreement that some form of "curation" (language TBD) would be helpful to these personas, because of decision paralysis. We also talked about helping to serve audiences new to Drupal by also guiding them toward the Project Browser on install, or by recommending some initial popular modules that most sites may want or need.

We brought back the idea of the Apple App Store and Google Play Store when discussing "what would make this project feel like a success?" but acknowledged that those stores don't do things to help you necessarily decide which to install; sometimes you just "download all three" and try each of them out.

We need to do more research on how people are currently browsing/"shopping" for modules. We may produce user surveys/polls in the coming weeks, but are not putting one out quite yet.

Meeting recording

See https://youtu.be/G3fJ0ZeMGQs

Next steps

TBD