Improve sort order of contributors

We are processing contributors as we find them in the "comments" property of the json representation of the issue ( https://www.drupal.org/api-d7/node/987238.json?drupalorg_extra_credit=1 → ).

Then we assign them to an array using the "username" as keys: https://git.drupalcode.org/project/contribution_records/-/blob/1.0.x/src...

But there is no ordering.

I will try to explore a sorting option based on the contextual activity that is being pulled via ajax.

Note that the order in d.o seems to be: number of patches, then number of files, then number of comments.

Given that patches and files should not really be _that_ important, I think the order should just be based on the activity volume. In this case, it could be: patches + files + comments, and then have a unique order.

d.o issues are going to go away so we can't do anything specific to them, it has to be as generic as possible.

Using the MR and the logic described above, we'd get this instead:

I think this is meaningful and simple enough,.

This is ready to review.

This is only available for maintainers, and they can choose to save the order.

Attached is a video with a voiceover about what's going on.

Merged. Hopefully this is good enough and the sorting is meaningful enough.

We can iterate through this in a follow up if needed.

fjgarlin → credited drumm → .

@drumm's idea on weighting:

We might want to do some weighting, multiply comments by 100, commits/files by 10000 or something like that. Effectively making it primary/secondary/tertiary sorts with only one comparison underneath

I’ll do: files x 100 + comments x 10 + reactions x 1

Committed the above suggestion.

This is my first time seeing the new UI. I'm thrilled we've got a tool to help us construct better commit messages now! Huzzah.

Sorry to reopen this, but the new sort order still seems not to match the ordering from the d.o. For example:

https://www.drupal.org/project/drupal/issues/3538854 🐛 APCu requirement for 32MB always displays since APCu 5.1.25 Active
vs
https://new.drupal.org/contribution-record/11419172

(See attached screenshots)

I believe the new is now sorted chronologically by each user's first comment in the issue.

1. It'd be great to at least get back to the original heuristic.
2. Better yet, it would take GitLab MR review threads into consideration, too (not just that pushing commits == "patches").
3. Ideally, whatever the default order was in the UI, there's be a drag-and-drop for the rows in the UI so we could reorder when the heuristic gets it wrong.

Happy to split off follow-ups for any/all of this, but I'm reopening since it seems like at least point #1 was the original intention here and it doesn't seem to be happening.

Thanks!
-Derek

the new sort order still seems not to match the ordering from the d.o
The functionality added will only change the order if the maintainer of the project decides to re-sort the rows.

The activity comes dynamically from the d.o issues and the related MRs (eg: comments made in the MR), if any.

For example, see this: https://new.drupal.org/contribution-record/10135146, you can see that the d.o issue has 134 comments, but the activity linked to me is at +400 comments, because those come from MRs.

We cannot do the sorting before rendering due to the potential volume of calls and waiting time. We also don't want to do it automatically because this might not be important for most maintainers or issues with 1-5 people involved and will start moving things around the page until all the info loads.

Maintainers can choose to order it at any time, and that will set the order to whatever activity happened at the time.
Also, bear in mind that we are moving all issues to gitlab soon, so the activity will be pulled from the gitlab issue and related MRs.

I'm marking this as fixed again as I think it still offers the sorting, but it's a kind of opt-in from maintainers and it's just 2 clicks away, if desired.

I requested this behavior originally - if the sort order changed as HTTP requests complete, that’d swap out what’s under the maintainer’s cursor, and lead to accidental crediting.

The other option would be to hide the entire table until all requests complete, or a timeout is reached. We decided it would be best to use the behavior that was implemented. We can always do more followups in separate issues if something better seems practical.

Automatically closed - issue fixed for 2 weeks with no activity.