Maintainers block on projects should show maintainers of project, not committers

This will deprecate the need for #1073344: Maintainers block shows up on projects that don't/won't have commits.

#2275331: Add user pictures to project maintainers list would be nice to have, but should remain a separate issue.

For implementation, this block is in versioncontrol_project now, which is why it is focused on commits. We should either move this to project module, with versioncontrol_project altering in commit info; or make it wholly custom in drupalorg module.

I was just about to open this same issue, so I'm glad I found it. I do have to say, it was really hard to find, and I had help!

• In what order should the maintainers be listed? In maintainers.json the order appears to be somewhat arbitrary they are listed aphabetically.
• Would it be reasonable to also state each maintainer's permissions, e.g. via a title text, icons or a subline?

+

Some thoughts:

1. Sorting alphabetically would be good. or by the number of commits.
2. There is a maintainers tab (for administering maintainers), should we reuse it to display permissions info to anonymous?
3. Instead of plain text/link, can we display avatars just like "My mentors"?
4. Display at the place where the author is currently, underneath the project title.？As maintainers are similar to the author.

+1 for replacing the block with a simple list of maintainers.

We should also think about the placement of the block. At the top of the sidebar is very prominent. We want to acknowledge the maintainers, and for end-users to know that there are actual people putting effort into what they are using. That said, I see the primary goal of a project page to provide information to people evaluating and using modules/themes/etc. Only insiders can make a judgement about a the potential quality of a project based on who's maintaining it.

In danger of sidetracking the issue ... The current headings of the sidebar is:

• Maintainers for XXX
• Issues for XXX
• Documentation
• Resources
• Development

Maybe switch to:

• Documentation
• Resources
• Issues
• Maintainers
• Committers
• Development

Removing ‘Change the current block to say "Committers".’ from the proposed resolution. With moving more toward relying on our GitLab instance, and simplifying www.drupal.org ahead of updating to Drupal 9, bits of www.drupal.org that rely on our local database of Git metadata will have to be removed and replaced where needed.

Since we’ll be removing some helpful information in evaluating a project, when recent commits were made, I opened #3246296: Revamp the “Development” block on project pages to do an initial cleanup of Git-related links on project pages.

This is what I'm looking at using. The best ordering I can think of is by last logged in time. Many projects have quite a few maintainers, we can show the first 6 and a show more/fewer toggle.

This has been deployed.

There are a few issues with "See more" link.

1. I think it should be rendered only if there are more maintaners to show.
2. It misses "href" attribute which makes it non-focusable. Acually, it shouldn't be a link at all. That's just button.
3. When using "aria-expanded" attribute the label should remain neutral.

We've lost the date of each person's most recent commit, which was useful information as it gave you an idea of how actively a project was being worked on.

> The best ordering I can think of is by last logged in time

Would each person's most recent commit would be possible instead?

>We've lost the date of each person's most recent commit

I think this must be another block

We've lost the date of each person's most recent commit, which was useful information as it gave you an idea of how actively a project was being worked on.

That's still available on the committers' page, e.g.: https://www.drupal.org/node/640498/committers

OTOH there's no longer a link to that page.

Sorting by last login date is a little random, might it be possible to change it to alphabetical, or something else?

As far as I remember one of the reasons for replacing the old block with this nice new one was to remove one more dependency on the custom code on drupal.org that is currently importing commit data. I think the goal was to remove this whole code in the medium term and rely on GitLab for these things. E.g. you could see the commit history of a user on the GitLab profile page and you could see the latest commits in the activity log or commit log of GitLab, which is now also linked from the project page. If I remember correctly, this was done to make maintenance easier and prepare for the upcoming migration to Drupal 9. I might be wrong, though.

Sorting by last login date is a little random, might it be possible to change it to alphabetical, or something else?

Personally, I like that it is a bit random. That way, each co-maintainer will have a few hours of fame and no maintainer is always listed first, just because of their user name.

> As far as I remember one of the reasons for replacing the old block with this nice new one was to remove one more dependency on the custom code on drupal.org that is currently importing commit data.

That's not been communicated in the IS here.

My impression was always that it would be the same UI, but different source data, with just the addition of the profile picture.

That's not been communicated in the IS here.

Yes, it's obviously not been the main reason (the main one is mentioned in the IS, I guess). As I said, I might be wrong, so take it with a grain of salt. I thought it was mentioned in an issue somewhere, but I can't find it now. Maybe it was in Slack. Or I don't remember correctly. I just tried to shed some light on why the sorting based on recent commit data might have been removed.

I think it should be rendered only if there are more maintaners to show.

Good catch, I’m deploying a fix for this now. I’ll work on the accessibility issues soon.

As far as I remember one of the reasons for replacing the old block with this nice new one was to remove one more dependency on the custom code on drupal.org that is currently importing commit data. I think the goal was to remove this whole code in the medium term and rely on GitLab for these things. E.g. you could see the commit history of a user on the GitLab profile page and you could see the latest commits in the activity log or commit log of GitLab, which is now also linked from the project page. If I remember correctly, this was done to make maintenance easier and prepare for the upcoming migration to Drupal 9. I might be wrong, though.

That’s exactly correct. Moving relying more on GitLab, without increasing our long-term maintenance burden too much, means some things will no longer be available on www.drupal.org. See #3248795: Reduce Drupal.org coupling to GitLab on git.drupalcode.org for other upcoming changes. In this case GitLab provides a better commit and activity logs, which are now linked from the Development block on project pages. GitLab also has a nice Contributors graph, like https://git.drupalcode.org/project/drupal/-/graphs/HEAD ; this one is slower to load, so I wasn’t sure about directly linking it in the project page.

Pasting my thoughts from Slack into this issue:

What I don't really like about this one is that it shows every person added to the maintainer list, despite of assigned access and/or number of real contributions. Some ppl were added to a project just in case the current maintainer is not available (anymore), and some might not want to be "exposed" in this widget on projects where they really haven't done anything at all.

Last login is a personal information that not everyone might be ok with. I don't feel quite comfortable with it, and I don't need to expose any reason for it. It's a personal feeling. Same goes for the thing being part of the maintainer list but not wanting to be shown on the project page at first.

tldr;
The things that concern me with the current change is the exposure of information that was previously not exposed (maintainers list and last login).

@mxh, actually the maintainers list was exposed a long time ago through API.
See example for CTools module.
https://www.drupal.org/project/ctools/maintainers.json

The three-column grid with rounded pictures does no look well to me, especially when there is only one maintainer listed. I really like the block appearance proposed in #2275331: Add user pictures to project maintainers list. It's more descriptive and compact. Of course design is a subject of personal preferences.

That design does include information that was deliberately removed in this ticket to reduce the gitlab coupling I think? But it does also work better for lots of us with usernames that don't contain spaces (of which there are many!), which wrap in funny places in the implemented design.

Another minor issue. The block probably shouldn't be rendered at all if a project has no mainainers.
https://www.drupal.org/project/easylink

tbh, I miss knowing which of the maintainers are for which versions of the module (based on last commit time). Should we just make it a habit to incorporate that into the body of the project node now?

It misses "href" attribute which makes it non-focusable. Acually, it shouldn't be a link at all. That's just button.
When using "aria-expanded" attribute the label should remain neutral.

This is now a button element, and aria attributes are removed. Thanks Chi!

tbh, I miss knowing which of the maintainers are for which versions of the module (based on last commit time). Should we just make it a habit to incorporate that into the body of the project node now?

We never exactly had per-version maintainership. GitLab does offer a few more options for push rules and protected branches. Documenting specific maintainer roles is a good idea. Core uses MAINTAINERS.txt, MAINTAINERS.md would be a good choice now. GitLab’s “code owners” is worth exploring, https://docs.gitlab.com/ee/user/project/code_owners.html. The project page is also good, particularly if it’s coupled with useful branch information for people using the project.

I really don't like this change because we lost all the information about the committers - the people actually doing most of the work currently. I would much rather keep the old information in addition to the new.

What we see now is only the "maintainers", for example someone who made 1 commit 10 years ago is listed, but not the "committers" who are currently working on the project, for example someone who made 50 commits in the past year (perhaps the ONLY commits made in the past year) is not listed because they're not a maintainer.

We also don't see the relative contributions anymore - how are we supposed to recognize who are the active maintainers without being able to see who is currently doing the work and who it no longer a participant (but still listed as maintainer because they started the project back in Drupal 5 so they "own" it.)

@drumm from #13

I see the primary goal of a project page to provide information to people evaluating and using modules/themes/etc. Only insiders can make a judgement about a the potential quality of a project based on who's maintaining it.

I agree, that's why I think number of commits/recent committers/last commit etc. like we used to have was far more valuable that what we have now.

What I don't really like about this one is that it shows every person added to the maintainer list, despite of assigned access and/or number of real contributions. Some ppl were added to a project just in case the current maintainer is not available (anymore), and some might not want to be "exposed" in this widget on projects where they really haven't done anything at all.

As mentioned, maintainership has been public, and I think its better that it is more-explicitly public now. When evaluating a project, knowing that it has maintainers is important.

Last login is a personal information that not everyone might be ok with. I don't feel quite comfortable with it, and I don't need to expose any reason for it. It's a personal feeling. Same goes for the thing being part of the maintainer list but not wanting to be shown on the project page at first.

Drupal.org’s session cookies are somewhat long-lived, 4 weeks. Drupal updates any particular person’s last login time is only updated on initial login, not on accessing the site. And these blocks are cached by Drupal’s long-lived block cache. So practically, this won’t reveal when you last visited Drupal.org, and doesn’t do a great job of showing exactly who logged in most recently.

The other easy orderings are alphabetical or by account creation time; both are worse. Last login time does get a rough measure of activity, not showing people who have moved onto other platforms/careers upfront is good.

Re: Sorting

Last logged in time is a very poor indicator to use for sorting. It doesn't relate to activity on the project at all. Sorting by last commit time would be far better.

BTW, I don't know about anyone else, but I never log out ... I'm not sure what my "last logged in" date is, but I guarantee it's not recent.

Another minor issue. The block probably shouldn't be rendered at all if a project has no mainainers.
https://www.drupal.org/project/easylink

I’ve committed a change which will show a “This project is unmaintained!” note.

Last login time does get a rough measure of activity, not showing people who have moved onto other platforms/careers upfront is good.

Not really true. Look at https://www.drupal.org/project/rules
The "maintainers" are listed in this order:

1. dasjo (last commit 6 years ago)
2. fago (last commit 4 years ago)
3. TR (last commit 1 week ago)
4. klausi (last commit 5 years ago)
5. mitchell (0 commits - never made a commit)
6. zhangtaihao (1 commit 8 years ago)
7. itangalo (1 commit 10 years ago)

Yet the people currently contributing, other than me, aren't listed at all.

If you go to the hidden page https://www.drupal.org/node/190124/committers you will see the current activity. And specifically, none of the above maintainers (except me) has done anything in the past year:

User            Last commit     First commit    Commits
MegaChriz       1 week ago      7 years ago     3 commits
TR              1 week ago      4 years ago     268 commits
jonathan1055    3 weeks ago     4 years ago     49 commits
AndrewsizZ      4 weeks ago     1 month ago     4 commits
nerdoc          7 months ago    7 months ago    1 commit
Liam Morland    8 months ago    8 months ago    1 commit
Pooja Ganjage   1 year ago      1 year ago      2 commits
martin107       1 year ago      5 years ago     2 commits

I would like to see the people who are CURRENTLY helping out get some recognition - as a maintainer I would like to encourage those people to continue helping out, and the least we can do is make it clear who has been doing the work.

… the change for unmaintained projects will go along with the next deployment, likely sometime this week.

TR - the reasons we can’t use last commit time has been mentioned in this issue and the parent issue, #3248795: Reduce Drupal.org coupling to GitLab on git.drupalcode.org. Put another way - the GitLab Acceleration initiative will overall be more work for the Drupal Association to ensure a smooth transition, migrate data, etc. Only if we reduce Drupal.org complexity, removing syncing commit data to www.drupal.org’s database and removing the old issue queue, then we can somewhat make up some of that time, in the long run. Missed commit data syncing is something that we do regularly have to work to correct, maybe about 1-2 hours per week of work, which we can start saving soon, not to mention not needing to get that entity & syncing working with a D9 upgrade.

And projects without code should have maintainers recognized too. There is no last commit time in a project without code.

I believe all the current functionality issues are working as designed (except for the no-maintainers case pending deployment), moving this back to fixed.

TR - the reasons we can’t use last commit time has been mentioned in this issue and the parent issue

OK, but that was just a suggestion I made, not a requirement. Sort by number of commits would work too. There are also other possibilities, which we can discuss. My point, which I stated above, was:

Last logged in time is a very poor indicator to use for sorting.

I also gave a very specific and detailed use-case demonstrating this, for a module that is used on 25% of all Drupal sites. Even though "last login" may suit some non-specific use cases, it's clear that "last login" is demonstrably worse and even wrong for Rules.

Status: Needs work » Fixed

So this is no longer open to discussion? Not going to consider exposing via a link the old (now hidden) committers page or even leaving the old block in place below the new one? Not going to consider any other sort order?

Note, I didn't say this work should be reverted, I said that the old information (now gone) was really important and the new block should be somewhat modified to be more relevant/helpful to the "primary goal" here, which you stated in #13.

The original scope of this issue was really to make the block a 'maintainers' block and not a 'committers' block, but there was obviously value in the old committer information too.

I would suggest that a follow up issue about 'promoting information about recent activity on project pages' be opened. (Or something along those lines, that might not be the exact title)

There will be constraints though:

• The commit history we had, that fed data into the old committers block, came from a Drupal.org commit database being synced over from GitLab. It's really redundant when GitLab provides that commit history itself - and not something we want to continue to maintain.
• We have a link to GitLab's activity page now added to the project sidebars, which can be used in a similar way to see who has recently been active. But it's not the format we're used to, and you do have to click through, rather than seeing it right there in the sidebar.
• Is there a much simpler API we could use to embed recent commit activity that would not require mirroring the whole commit history? I'm not aware of such at the moment.

Those are all points we could explore in a separate issue - but since we've committed to making GitLab our primary collaboration tool we'll need to accept its constraints as we begin to transition things over.

What about commiters page? Why isn't it linked on the project page anymore. Is it going to be removed?

It is the most accurate report about project contributors.
https://www.drupal.org/node/190124/committers

Went ahead and opened a separate issue for further discussion about committers information:
#3258275: Options for replacing committer views with transition to GitLab

Big -1 on this issue at least for core.

1. It is very misleading as to who actually has a governance role.
2. It can incorrectly expose an inactive maintainer who does not want to be contacted.
3. It devalues the role of the core committer. Our subsytem maintainers should be celebrated, maybe in a block at the bottom of the page? But the core committer role requires significant time commitment, vetting, and additional skills and responsibilities beyond the subsystem maintainer, and they should be celebrated.
4. Seeing the recent commit activity at the top of the node is valuable.

I think a better sort order would be by the weight of roles assigned to maintainers. Maybe you could still click through to see all the subsystem maintainers, but recent committers or at least committers with the VCS and administer releases roles should be weighted at the top.

> I think a better sort order would be by the weight of roles assigned to maintainers

That could still show inactive maintainers, or inactive project node owners (who presumably would be at the top with this sort order).

What about allowing the list of maintainers to be ordered manually in a project (I realise that is probably a LOT of UI work as it's currently a table with checkboxes, not easy to make draggable)

@hestenet asked me to clarify my comment.

I'm proposing sorting first by the maintainer permissions as granted on the "Maintainers" tab, followed by whatever more transient sort order you want within that.

This is a subset of what the 80+ maintainers page for core looks like:

On this list, we have many people who nominally have a subsystem maintainer role but have not contributed in a long time, with the "maintain issues" permission. Some are very active and help weekly or daily. Some contribute a few times a year, or are totally inactive.

And then, highlighted in my second graphic, we have the active, final decison-makers in the governance, who are granted "administer releases", "Administer maintainers", "Edit project", and/or "Write to VCS". (Provisional committers get a subset of those permissions depending on their role.) Even people who have governance roles but don't actually make commits (like pameeela, one of our team facilitators), are granted some of these additional permissions to reflect their governance role in the project.

The committer team is not only people who write to VCS -- we are a team including project management and design expertise alongside PHP and Javascript developer roles -- but all of us play a final decision-making role and the list is actively updated based on current governance. I think it is misleading not to weight those roles above the subsystem maintainers.

It's definitely valuable to be able to click through and see all the people with "maintain issues" permission alone, because their role in the governance is also important. But for core at least it could lead to a lot of confusion about who is actually responsible, and I imagine other projects might have this as well.

I also think weighting based on last login isn't the greatest even for the second sort after maintainer role; last issue comment might be better.

This does not address the issue of inactive project owners/committers for these more advanced permissions in contrib, but it could be an interim step at least that is not extremely misleading.

I think a better sort order would be by the weight of roles assigned to maintainers.

That is doable, I’ve opened a followup #3258623: Order project maintainers block by maintenance types.

I also think weighting based on last login isn't the greatest even for the second sort after maintainer role; last issue comment might be better.

If we follow the GitLab acceleration initiative to its conclusion, www.drupal.org no longer has data on last issue comment time.

Unfortunately this change now removed the quick summary that site builders and developers could use to assess how actively a module is maintained by whom.

Some information can be gained by scrolling through the activity or commit pages on gitlab, but that's quite tedious.

In addition, the contributor page on gitlab by default exclude merge commits as "contributions" so the task of actually maintaining a module is not reflected there. (That's probably a separate issue).

I had opened a separate issue because I consider the loss of that information and functionality a regression #3262961: Info about commits missing in Maintainers block