Request to weigh Group (and others?) more heavily in issue credit

Adding link with useful info https://www.drupal.org/drupalorg/docs/marketplace/contribution-credit-we... → and editing some bits of the issue summary.

This is my personal opinion, not DA-developer opinion:

A project sitting at 190K would have the same weight as 100K and it's almost twice as much utilized. Also, being honest, almost any project with +10K installs is a really good and robust module, because +10K site builders wouldn't have chosen it otherwise.

So I would change the algorithm slightly.

Option 1:
Have a different scale for this. 100K might have been meaningful in D6/7 days, but I think that's a big bar to get to. Also 100K to 200K seems to be a really big gap.

So I'd probably consider a smaller bar (5k?) and smaller gap (5K?).

Option 2:
Change to a logarithmic-like approach.
eg:
- 100 installs -> 1 credit (floor)
- 1000 installs -> 2 credits
- 10000 installs -> 3 credits
- 100000 installs -> 4 credits
- 1000000 installs -> 5 credits (almost no project would fall here)
- Core + strategic projects -> 10 credits

This would still put projects like pathauto or token with 4 credits per issue, but really good projects like group would have 3, useful projects would have 2 and new/unknown/very-specific modules would have 1.

Figuring these numbers or algorightms will be tricky but might help boosting contribution on good modules and companies might have a real incentive to sponsor development on them.

I'd probably change the issue title to "Rethink weighting of projects and credits" or something like that, because it's not just the group module affected in here.

I've gone and adjusted the title as you suggested as I agree this should/could be about more than Group. I opened it as such as I did not want to speak for other maintainers.

I also agree with almost everything you said and, if I'd have to choose, option 2 you suggested definitely seems like a nice compromise.

The only drawback is that it would still weigh a project solely on two factors:

• Whether it's considered strategic
• How many sites report using it

So I feel like either there needs to be a way to apply for the strategic status or there needs to be a second type of strategic label for this purpose. One label (10 credits) is managed by the DA, the other (5 credits?) can be requested on a per-project basis.

To circle back to my perspective: Sites built using Group are usually massive. The multi-million dollar type of massive. So it draws a lot of developer attention and money to the Drupal ecosystem that would otherwise simply not be there. Weighing that value solely on reported installs feels like it isn't fully giving Group the credit it deserves.

I know I'm speaking for my own benefit here, but if we were to go with option 3 or a mix of 2 and 3, Group would definitely be one of those projects that would request this "special status" in the blink of an eye. Having said that, I'm also aware of the fact that having strict metrics as opposed to a request process takes a lot of "politics" out of the process and will therefore be far more resistant to drama.

Either way, any progress would be welcomed. Thanks for your input @fjgarlin!

Thank you for the details. I agree that some of these complex domain specific modules are important for Drupal’s ecosystem.

Maybe for example some like Tome would also fall into this to make Drupal sites static which may entice a different type of customer.

There are also themes like USWDS and CivicTheme used by government that are critical.

The list goes on and on I’m sure.

It would be impossible to evaluate all modules to understand their importance so we’d need a set of criteria that these projects must hit to be included.

Then the maintainers or the community would have to nominate them.

This adds extra ongoing burden on the DA to review these so I’m sure they want to support this even if it does make sense.

Maybe it would be interesting to take the module ecosystem into account.

There is some extra metric at our hands that could be taken into account in addition to usage statistics: lines of code, test coverage, eco system, etc.

Chances are, that we get much closer to the "high value" modules by taking those into account as well.

I definitely like the idea of a rubric that could be used to grade the value of project contributions. @fjgarlin's three ideas for possible starting points are great, and while I like logarithmic for it's mathematical simplicity, I think it might miss the mark to focus to heavily on usage as the primary driver.

Usage statistics rely on unique sites that have the update manager module enabled if they run cron or manually trigger check for updates. The counts include non-production environments, including environments that may have been spun up for a test and then abandoned. The counts may not include production environments if the developers choose to disable update manager in production using something like config split. That makes usage statistics directionally accurate, but far from precise.

I could see a situation where a bad faith contributor spun up environments to boost usage numbers, but more likely is that we undercount usage on critical projects in the ecosystem. Case in point, Localgov is pretty essential to the growth of Drupal within government sites in the United Kingdom, but it shows no usage statistics at all. Similarly, GovCMS is an equivalent for Australian government websites and it shows only 12 installations.

Usage also misses the mark in highlighting relatively new projects that suddenly become key areas for contribution. The Drupal AI module comes to mind here as it only has 463 sites reporting usage, but is under active and rapid development.

As @kristiaanvandeneynde mentioned, Group and Commerce sites often have a significant number of total active editors and logged in users. I know of a Group site with well over 2,000 active editors as an example. It's a single installation, but represents a massive amount of total content and reach. Those sorts of sites are probably some of the most important to ongoing usage and support of Drupal.

Another counterpoint to usage, there are modules that are heavily used, but only releasing maintenance fixes. These heavily-used-and-stable modules don't need much contribution.

Likewise, there are heavily used modules that have that usage despite not having a stable release. You end up with thousands of sites running an alpha or beta version because the functionality is critical to the use case. It would be awesome to increase weight for contributions to help get these modules stable and get more of the ecosystem covered by the Security Team.

I agree that reviewing every single project to set a weight would be burdensome for the DA. That said, I don't think it is out of the realm of possibility for a working group to be formed that could present high impact projects to the DA for adjusting their weight. There are 9,355 modules currently claiming support for Drupal 10 that are not marked as "obsolete" or "no further development". (There are similarly 349 themes. I couldn't get the D10 support coverage for distributions easily, but there are only 202 distributions that are marked as "has a supported stable release"—so it is some number less than that 😉.)

A few steady contributors giving a little time to this sort of ranking could have a huge impact without as much strain on the DA. It would also provide an opportunity to highlight what type of support is needed for the project in question. Maybe it's a stable project that just needs better documentation. Maybe it is a project that needs a more active maintainer and becoming that maintainer would boost credits for the module in question. I can think of lots of helpful scenarios to improve the quality of a module and its impact on the ecosystem.

Great topic to bring up!

To add more context:

Less than 20 contrib modules are over 200.000 installs:
https://www.drupal.org/search/site/*?solrsort=iss_project_release_usage%... →

No contrib theme is over 200.000 installs:
https://www.drupal.org/search/site/%2A?solrsort=iss_project_release_usag... →