Offering to co-maintain Edit UUID (edit_uuid)

Hello, I have tried everything to reach the maintainer, but had no responses. I'm willingly interested in maintaining this project.

Since the project is covered from the security advisory policy, project moderators will not add as maintainers/co-maintainers/owner people who cannot opt projects into security advisory coverage.

Only the project maintainers can decide to accept the offer.

I have always hated seeing developers who offer to help get turned away because they haven't developed a unique module from scratch meet the requirements of the `permission to opt into security advisory coverage` process. I understand that process has made Drupal more secure which increased government adoption, but at this point in the Drupal project arc can we really afford to turn away people offering to contribute?

@makbay has been a member of the community for almost 8 years with a number of credits for fixes.

@avpaderno would it work if I took over the project and added @makbay as a co-maintainer?

I honestly don't even know if I need this module yet. I came across this issue while looking at the options for dealing with a UUID problem I have, but I'm willing to work with @makbay to get a D10 version released and work with him to clear up the code to the point he could use it for https://www.drupal.org/node/1011698 →

1. Obtain basic Git access and create a project for your code.
2. Get your project into a state you feel is release-ready; ideally, you would commit the project early and have a track record of several weeks/months of commits so that application reviewers can get an idea of your development and maintenance style.

Thank you so much, @kreynen! I was starting to lose my motivation to contribute due to the maintainership process, but your message truly made my day. I really appreciate your willingness to step in and help keep this module alive.

If you take over the project, I would be more than happy to collaborate with you to get it cleaned up and fully compatible with Drupal 10 & 11. Looking forward to working together!

@avpaderno, could you help with the necessary steps to proceed?

To be added as maintainer, @kreyner needs to create his own offer, which needs to sit on the project issue queue for 14 days.

That does not change what I described in my previous comment about this offer, though: Project moderators will not add as maintainer / co-maintainer / project owner a person who cannot opt projects into security advisory policy; only project maintainers can.

📌 Offering to maintain Edit UUID Needs review

I will add that @makbay could fork the project into its own namespace and continue development.

Would have zero delay and would more closely align to how the rest of the world handles abandoned projects (the whole “steal a namespace”/supply chain attack of Drupal is an oddity).

Not required if @kreynen receives and assigns maintainer rights, mostly posting this for other developers who find themselves in a similar situation without a benefactor to volunteer in their name.

@cmlara GREAT point! Forking is WAY more controversial in Drupal than it should be, but that is in part because of how the namespace is used. Composer/packagist made forking outside of the drupal namespace an option (the way most of the PHP ecosystem works off our tiny island), but that is RARELY used in Drupal. Many universities have shifted from maintaining code on Drupal.org to registering their own namespace on Packagist, but this is primarily for modules so custom they serve no value beyond as an inspiration/example outside of our codebase.

https://packagist.org/packages/az-digital/, https://packagist.org/packages/uriweb/, https://packagist.org/packages/utexas, https://packagist.org/packages/ucdavis/, https://packagist.org/packages/cu-boulder/ and (of course) https://packagist.org/packages/university-of-denver/ are just a few of the organizations I know of managing our Drupal (and WP) code outside of the official project namespace.

Managing forks that way does get confusing as Drupal core would assume that myforkedprojects/edit_uuid was actually drupal/edit_uuid if you were using something like Update Status.

I did exactly what you are describing with https://www.drupal.org/project/webform_pardot_handler → when a maintainer would neither update, nor add co-maintainers to help. I was eventually given control of https://www.drupal.org/project/webform_pardot → and backported the improvements I had made in the fork so they were available to everyone using the module at the drupal/webform_pardot namespace.

I no longer use Pardot and handed the project off to baikho → when it was clear he was committed to moving more of the issues forward than I had time/interest to look at. This is the way to keep the drop moving.

This isn't pressing for me, so I'm willing to wait 2 weeks before escalating [#350439]. I hate it when people try to put pressure on me to bypass process, so I try to follow any process any group willing to volunteer time maintaining the Drupal infrastructure has decided they need to stay sane/have some work/volunteer/life balance.

I moved 📌 Offering to maintain Edit UUID Needs review to the Drupal.org Project Ownership queue. Shouldn't be too much longer. I've closed this issue as it will never get resolved in it's current form. Works as designed seemed appropriate.

I added @makbay as a co-maintainer. I know ~a month seems like a long time to wait for a change like this, but Drupal has this process to prevent issues like https://www.theverge.com/2024/10/12/24268637/wordpress-org-matt-mullenwe....

Thanks @kreynen!