Add log of maintainer level changes to project pages and provide notice when project moderators add/promote maintainers/co-maintainers

FWIW each project has

https://git.drupalcode.org/project/diff/activity

And all projects master feed:

https://git.drupalcode.org/groups/project/-/activity

Click Team tab at the top of each.

Data is also available on the API

IMHO, the peer review of the code committed to a project is much more important to discover supply chain attacks than the proposed highlighting the log of maintainer level changes. There is no history if maintainer level changes increase the risk of supply chain attacks, so the perceived risk is IMHO theoretical.

Of course, implementing this highlighting wouldn't do any harm, but resources is always in short supply, and any benefit this proposed measure might bring will probably not be worth the expense of implementing it.

But if anyone wants to donate resources to implement what is sought here, please go ahead!

PS: For the record, ownership changes should be logged in the history of the project page. For an example visit https://www.drupal.org/node/3001729/revisions – notice the entry for April 13, 2024. However, this entry in the history log was created manually by me. It would be better if it was created automatically.

It has been an ongoing regret that when I very first implemented the project level permissions and maintainers tab on d.o, that I didn’t build this into it from the beginning. 😢 Completely aside from the supply chain aspects and whether end users would care to see it, simply for the benefit of d.o site admins to figure out WTF is going on in various conflicts and disagreements that have come up, it would have been incredibly handy.

Also note that while issues are planned to migrate to GitLab, AFAIK, the long term plan is to keep both project nodes and releases on d.o. So the fact GitLab has a feed for some useful things doesn’t solve that the historical view of changes to the “maintainership” is lacking and would be useful, even outside the scope of the parent meta.

There’s probably an issue somewhere in the GitLab migration family of issues about how to keep project-level permissions in sync between the two worlds, but I don’t have a handy link. And yeah, the two have different models and not all perms cleanly map back and forth. It’s an unfortunate situation. If only 17 years ago me knew what I know now. 😂

I am not sure that showing a notice when project moderators add a new maintainer/co-maintainer or promotes a co-maintainer to maintainer covers the most important cases for which somebody should get a notice.

Now that maintainers/co-maintainers can remove themselves from the project from the GitLab side, even project owners can remove themselves from the project. That is an equally important change for which a notice should be shown.
What about the cases where, out of two maintainers (including the project owner, which is just a maintainer for which the permissions cannot be adjusted), a maintainer becomes inactive?
What about the cases where the project owner is no longer active, and a new maintainer is added by the existing maintainer?

Showing a notice only when project moderators add or promote somebody seems to call out what project moderators do, as if they could have done anything wrong. Truly, the chances that a maintainer/co-maintainer added by project moderators does something wrong are the same chances that a maintainer/co-maintainer added by maintainers could do something wrong.

Probably this issue should be split in two: an issue for logging when there is a change in the permissions people have on a project, and an issue for when showing a notice in the project page, if the notice is shown only for actions project moderators do, since project moderators is not a concept the Project module have.