Remove Git-related information from profile pages, link to git.drupalcode.org profile

I like the suggested wording.

I'd prefer the link to be somewhere that doesn't move easily so it's predictable and easy to reach this information, middle top would be a good candidate by that measure.

> "We can either list projects maintained, without commit counts, or remove it."

I would vote for removing it because it's easiest, but in good conscience I can't. I would be happy if: "As a Drupal.org user, I want to display the projects I contribute to, so that people know I am a contributor to the Drupal community." But, as we probably can't trust that to just be an entityreference field the user fills out on their own, I'd be interested - what _are_ the "types of maintainership" because I'd probably be happy with limiting to just one.

> For the link to the git.drupalcode.org profile, we need to decide on wording and placement.

I cannot think of something to call Drupal's GitLab installation except the "Drupal Git Server" - but "Drupal Git Server Profile" seems a bit wordy. But maybe "Git Server Profile" would do. Drupalcode.org redirects to git.drupalcode.org, so maybe "DrupalCode Profile" could work?

I like left sidebar the best for placement; it feels natural to me to think of that as "all the places you can reach me / learn more about me" and my profile on an external property (albeit a tightly coupled one) sits well there for me. I think a button would get lost in the main page content.

All this just my $0.02. :)

Drupalcode.org redirects to git.drupalcode.org, so maybe "DrupalCode Profile" could work?

FWIW, I prefer some version of "DrupalCode Profile" to "git.drupalcode.org profile".

I like "DrupalCode Profile".

This is still very rough, but here's a basic visual mockup of some options we could look at here:

Lack of "commit counts" will make drupal die. I don't want to contribute to modules anymore because of it.

To restore commit counts we would need the same functionality to exist in GitLab, either as a display somewhere in the GitLab 'Activity' UI, or as an API that could be called to get a specific user's commits per-project (better as a direct display in GitLab). I know GitLab is interested in accepting contributions, so it may be worth coordinating with @nick_vh to understand how to do that.

In the meantime though, this issue needs to be completed as is, so we can complete our accelerated migration to the rest of GitLab's toolset.

This is major
We shouldn't deploy this level of changes with a lack of replacement
We must rollback it and think about it better

To those decrying this recent change:

Could you explain why issue credit - which is still displayed - is not enough?

Could you explain why issue credit - which is still displayed - is not enough?

• Timeliness: Issue credit in D.O just display info in the past 1 year. Not all the history.
• Code contribution: Issue credit contains all the forms of participation: a comment, a review, or just some irrelevant discussion, 'commit count' can reflect the code contribution on each different project.

Adding some points from the Slack thread about this regression

https://drupal.slack.com/archives/C1BMUQ9U6/p1652772409621139

HR issue

- Previously HRs could build their interviews around a list of projects, developer committed to. Despite the fact they are outdated in a terms of drupal.org ( 3+ months ago as per credits system)
- now there is no human readable way to show list of projects developer was involved in, when he/she is not a maintainer of a project. There is a similar thing in GitLab https://git.drupalcode.org/users/podarok/contributed - but let's ask HRs is they can understand what that table of tables means ( I assume - they will hate us )

Developers

Previously user profiles were included in CV, when there was something to include. Example https://www.drupal.org/u/anprok - Andrii had ~2000 commits to different projects. Yes, they are ~1.5 old, but still, for the career it means something. Now it is gone.

Credits system

For developer/user to get credit there is a bureaucracy
- you must to create an issue, create MR from it, proceed to the merge and Fixed status of issue in order to get credit which will disappear soon in your profile
- if you created MR in GitLab without a connected issue - your work is hidden from the eyes.

Suggestion
- rollback Commits per project to User profile until we have a better replacement ( GitLab improved bu us or something )
- discuss this with wider community
- keep Projects Maintained, because it improves profiles of Projects Managers, which are usually empty now

Summarizing #14.

• Code contributions are not respected anymore unless you create an issue for each commit which is tedious.
• Inactive contributors got clean profiles despite all their hard work in previous years.

To clarify why this is important. Many Drupal related companies rank the candidates based on their contributions to Drupal. So when you apply for a job the first thing you will be requested is a link to your drupal.org profile. That was a good motivation for contributing escpecially for junior developers to accelerate their career growth.

I think that the main complaint of most people is that:
Just the contributions of the last year are visible at first glance.
Since many people use those metrics as a marketing tool (It does not matter if we are talking about a company looking for clients, or an individual looking for a corporate/freelance job) and considering that, in the Drupal ecosystem, issues in the queue might take months/years to resolve, even in very well maintained modules, the 1 year "visible" history might be narrow. Having a developer who took a 6 months break from Drupal (Or just from public contributions specifically) appear as someone who is not active in the community is inaccurate and will probably dishearten many people from taking the
extra step and making their project specific work more generic and contributing. Even as it is now, I think we all know that "gatekeeping" is a problem in the Drupal community and we need to try and add more incentives for people to contribute.

Having said that, @lawxen I strongly disagree that

Code contribution: Issue credit contains all the forms of participation: a comment, a review, or just some irrelevant discussion, 'commit count' can reflect the code contribution on each different project.

is a bad thing. Reviews might be even more important than code contribution, since the "needs review" is the stage most long running issues get stuck at. Also, maintainers decide if someone gets credited or not, which means that "irrelevant discussions are not credited.
Additionally, as it was mentioned multiple times, it is very easy to bloat the commit count on personal / sandbox projects that are uploaded to drupal org, just to appear active, so just showing the # of commits in some project, is a bad metric. It would still be nice though, to reward people somehow, for publishing their work.

@podarok The "projects maintained" area is still there, is it not? Unless I understand something different than what you mean. Also - discuss this with wider community Where would there be a more public space for this discussion, rather than the issue queue?

Maybe adding a total contribution count next to the "view all issue credits" (And making a bit more "eye caching") and having the visible history take into account a broader time frame, might alleviate some of the discontent.

Edit: The /issue-credits page could get some love as well, so that it can be used for personal marketing purposes maybe."

Wanted to add a couple of screenshots here to show some follow-up that will happen. This adds the link to the git.drupalcode.org profile where you can see user activity (e.g: https://git.drupalcode.org/drumm)

These aren't an exact replacement for commit counts per-project. But they do provide similar signals about users code-activity.

And then there are these credit and projects maintained displays which already exist:

To reiterate what I said in the Slack thread about this issue:

I think there's a lot of good conversation about this, and thank you to those who took the time to summarize this in the issue.
Appreciate also those who linked in our recent sessions and other communications about this.

With the migration to GitLab there are things that we are going to gain and things that we are going to lose. And for some of the things we lose, it's not because they are not valuable (they are!) it's just because we don't have that functionality in GitLab."

But it may be possible to recreate that functionality, or to find equivalents within the GitLab toolset. So for example, if we can explore elements of the GitLab api to see if there's something beyond just the 'Activity' feed that could be used to create commit-counts per-project, we might be able to restore that.

But it's a change of thinking from building it custom, to finding out how to do it with the toolset we're moving to, because we just won't have the capacity to do both.

We'll keep following all your feedback in the issue - and especially if anyone has an interest in exploring the GitLab APIs to see what might be possible, you may be able to help contribute to a solution for us here

Thanks for all the thoughtful replies here. I definitely see multiple sides of this issue.

I wonder if it'd be possible to restore the existing functionality in the interim. Yes, it'll go away again when we finally cutover to pure Gitlab. But it doesn't *really* hurt to leave it turned on until a few months (?) from now when that actually happens, right? Meanwhile, hopefully "we" 😅 can come up with a solution using (or extending) what Gitlab provides. But we don't have to hide all this useful information now, do we?

@dww, possible solution would be to figure out if there are Gitlab APIs that will provide such data (commit counts) without building custom solution on drupal.org.

Indeed. I’m saying we could turn the bespoke feature back on until the earlier of these two events:

1. Someone implements something functionally equivalent on Gitlab
2. We’re ready to cut over to full Gitlab and have to revert this feature.

I believe we’re still months away from #2, so let’s restore the bespoke thing until we have time to replace it.

Thanks!

+1 #20

Thanks @dww

+1 #15.

Sounds reasonable to me.

+1 #15

Fair point on on-going maintenance of a dying system. But otherwise, we're still not actually very close to getting d.o past D7, right? So it's not like we're ready to go live with a D9 d.o port and these commit tables and supporting code are the last things stopping us. Precisely since it's mostly independent of everything else we're trying to move to Gitlab, I'd be in favor of leaving the old thing in place (and instead of removing it, maybe imposing a moratorium on supporting it), to give ourselves / our community time to implement a suitable replacement.

I think the "Projects mainainted" section needs some tweaks.
Currently it may show projects that you've never actually mainainted but have access to. Just because someone gave you permissions to them long time ago. And you know drupal.org does not allow you to "unsubscribe" from such projects.
Also it includes obsolete projects and sandboxes. Can we give users some control over it? Something similar to "Pinned Repositories" functionality in GitHub.

It would be nice to have one chance to screenshot/save the old metrics, if they were put back for a short amount of time.

Transition to Gitlab opens access to different metrics, for example, each project has tab "Contributors" with interesting visualizations for those who want to see https://git.drupalcode.org/project/feeds/-/graphs/8.x-3.x. This visualization shows general trend for a project, data per branch and option to see only selected years, as well as all commits for the history of the project.

Maybe we can work with Gitlab to add similar visualizations to the tab on personal profile https://git.drupalcode.org/users/irinaz/contributed

It would be nice to have one chance to screenshot/save the old metrics, if they were put back for a short amount of time.

@tim.plunkett Just to mention the work-around in this thread, most of the time archive.org can provide a snapshot, but not entirely up-to-date.
E.g. the latest I could find for your profile is from July 2021, https://web.archive.org/web/20210728230213/https://www.drupal.org/u/timp...

Opened #3281946: Investigate the feasibility/performance of using the GitLab api to provide counts of commits per user per project as a follow up to investigate commit counting via GitLab API