Modify algorithm for weighting project credits by usage

This has been deployed and contribution rank recalculated.

I just looked at https://www.drupal.org/drupal-services.

It seems like a Drupal core gave organizations a huge lift. Which is great, but doesn't highlight distributed contribution. Mediacurrent seems to break the pattern - they have a lower Drupal core credit, but maintain Metatag and other large modules. MDSystems also has a good spread.

Was the intention to give such lift to Drupal core contributions? I understand its a big important piece. But so is the contrib ecosystem.

While I understand the reasons, and support attempts to prevent gaming the system, I think it's a shame that this devaluates credits on "community project" type projects. Those projects have no usage by definition (at least, not registered in a db), yet some of them have an enormous impact.

I'm really trying to understand why this update would result in our organization dropping from near the top of page 2 to page 6 when we have a fairly high number of commit credits relative to the other organizations?

I'm concerned about the impact of this change. The weighting of usage seems to have shifted so that only Drupal Core or perhaps a top 10 module is going to get much credit towards rank. This boosts the relative value of Case Studies and also seems to seriously boost the paid sponsorships for the DA. It also looks like simply creating a lot of projects is weighted with more value than the commits required to maintain them.

I'm the architect for Drupal at my organization and one of the few dedicated Drupal developers. Our practice here is new. The agency has traditionally focused solely on Sitecore. I look to my involvement here as an opportunity to build a culture that includes contribution. With that in mind, I was able to get permission to work on contrib between projects. I chose to dive in with Viewfield, a module I participated in development of many years ago. I spent a lot of time cleaning up the queue for Drupal 7 and Drupal 8 issues, building new releases and starting to implement testing in the D8 branch. I was able to report back that these efforts had bumped us up the service page ranking to page 2. While the net result of that doesn't mean a ton in terms of leads right now (we've only had 8 referrals to our site from D.O. since July 1st) I was still able to make the case that the visibility would work in our favor as we try to build the practice.

The current updates to the algorithm make those contributions far less meaningful. If page rank was truly important to my org, then I'd be better off writing case studies than contributing modules, and more importantly - maintaining them. With 33k installs, Viewfield isn't a brand new, insignificant module either, but clearly it falls below a threshold where commits to it are valued.

That's incredibly demoralizing, to move from page 2 to page 6 and see how little that work is now valued. That will make the process of making a case for contribution at organizations such as mine more difficult.

I understand that one focus of these changes is to reduce the benefit some organizations have gotten through a more shotgun approach to small, almost scripted contribution to multiple projects. A thought I'd add to future algorithim considerations would be this:

1) Increase the value of contribution credit based on the number of contributions to the same project. A single commit to 100 projects should be worth significantly less than 100 commits to one project. That encourages people to actually maintain the projects they put on D.O. and not try to game the system through a shotgun approach.

2) Weight the number of contributions to single projects higher if that project is also a supported project by the organization. That encourages organizations to both contribute code and maintain that code. Even if the code is used by fewer people than Drupal Core, it doesn't need to be a top 10 or top 100 module for the effort to be valued.

If we're gonna extend our policies and forbid attempts of gaming the credit system, then the algorithm should be public. We've seen that the community is the best protection against misuse.

The general algorithm and factors used is public, in code at https://git.drupalcode.org/project/drupalorg/blob/79f1d09acbd9258eb0cd8e... the drupalorg_org_credit_weights configuration is not public.

I think it is fine keeping the weights private, for what its worth. This is a hard problem of "how do we determine how valuable some project is?"

This change just gave option for easier gaming of the system and making top projects even more active (excluding Drupal core).

This could make a long term impact on activity and contribution between high, middle and low used modules.

Why someone would collecting credits on middle or low used projects, while he can now focus on top 20 contributed modules and get more credits there. Submitting a smaller patch to each of these modules would probably get more points then on 50 others.

More time-effective for getting credits and ranking, less effective for the community.

Taking some number in the calculation without context is not good:
- project activity over time - is it declining, or not. There are lot of D7 modules which essentially are not going get D8 version
- the complexity of the project - not all most used projects are complex, they are just popular while everyone needs them

There is a lot of other factors that can be added, as test coverage, ecosystem, etc..

Just a question:

Do we have documentation in Drupal.org about this change? (Considering weighting project credits by usage)

Thank you all

I think that this will help you:
#3086885: Marketplace ranking Algorithm: Weights & Measures