Proposal - create a 'Project Update Working Group'

I have read the RFC and find that it is well thought out and respects the maintainers and the needs of the community. As with any proposal that has lots of steps it will only be by using it will we find out if adjustments need to be made. Overall, I this will bring another improvement to the number of modules ready for the next major release Drupal.

Thanks to everyone who worked on the proposal.

+1

One thing that may need consideration is what to do if the dev branch of a module is significantly further ahead of the latest tagged release. Should the working group tag a release off HEAD or cherry pick the fix for a smaller change set? The former could be more disruptive, and the latter could be more difficult since presumably the existing patch would be against HEAD.

I think this is a good idea, and will help lower the burden/barrier of keeping your Drupal sites up-to-date. The proposal seems well thought out. Maybe build in some kind of regular review step? Like at the start of each new release cycle take some time to reflect back on the previous cycle and identify any policies or steps that might need udpating.

Overall a big +1 from me though.

I have read the RFC +1 to it.
Here's some from the RFC

This includes modules where the maintainer has requested assistance as well as modules where the maintainer is no longer active.

How are we considering a maintainer is not active? There could be possibility that maintainer is not active on that specific project but s/he is active on drupal.org.

Some of the working/activities of the PUWG(Project Update Working Group) is similar to the project ownership group( https://www.drupal.org/project/projectownership → ) and it will work in the similar way the drupal.org project ownership group is doing which is already a success story in itself

+1 on the proposal. It would drastically help with getting many projects over the final finish line in an orderly manner. There are always exceptions to the norm (as seen in questions #4), but those can be handled in a one-off manner. Let's not let the exception complicate the path forward for the vast majority of modules.

+1 This is well thought out. Having been involved with many D9 to D10 upgrades this past year there were many times where I wished for a system just like this. Even more so when our developers provided patches that got little to no response. The fewer patches we need to include in our builds and re-roll when they become outdated would save a lot of time and be better for the community when people are evaluating Drupal contrib readiness.

I have similar questions as #4 where HEAD has significantly more changes than what's in the latest release.

HUGE +1! I do have one question regarding

If the module has opted in to Security team coverage, the member of the Project Update group MAY opt the module out of this coverage

Is there a communication that should come from the security team regarding a change to the advisory coverage? Some users may re-think the use of a module that is "on its way out" so to speak.

This is great.

The proposal → looks great. 👍

I've was following similar process for D9 to D10 upgrade for number of modules / themes.
Still have one ot two modules sitting at D9 which we can use at a trial for the process.
Usually, the 95% of maintainers are pretty responsive and add you as a maintainer (in about 4 out of 5 cases).

🙋‍♂️ Happy to self-nominate to join the group and help out with D10 update leftovers and upcoming D11.

Personally I believe we are a bit too afraid of natural attrition. There is advantage in letting modules "die out" rather than breathing artificial life into them where others do not step up to maintain them.

Upgrading modules without a maintainer will take a large reason for the community to adopt a module away. At the same time it can hurt more active modules as well since they will see lower adoption.

I would encourage the team members to make sure to give serious weight to 6.5 and use it as a reason to decline updating a module whenever possible, even if the module is not a 100% replacement those can be handled as feature requests in the alternative module.

I would like to suggest the following minor additions to the policy:
7.4 -- Add: The team member must also record in the commit message that it was made on behalf of the working group not the original maintainer. This ensures the commit message itself (which is immutable without changing hashes) always retains the record that it was not done by the previous maintainers. This partially helps meet the requirements of GPLv2 Section 2.
7.6 -- Add: If the team intervenes to make a release the Release Notes must include a prominent notice indicating the release was made on behalf of the working group. This also helps meet GPLv2 Section 2.

The Working Group may want to consider if they proactively wish to avoid any modules that contains registered Trademarks.

The release MUST follow semantic versioning rules for backwards compatibility.

I would suggest defining these parameters explicitly as they relate to the Working Group. There is already a decent amount of contention inside of Contrib as to what is a semver breaking change and what is not. It would likely save the working group a significant amount of time if their policy was standardized.

Security covered projects appears to be the elephant in this discussion.

On one hand the module is essentially completely unmaintained, if a security issue comes forwards it will just end up being public (unless it was a maintainer who asked for help porting to a new version). Keeping it security covered may lead to more issues similar to Colorbox (SA-CONTRIB-2022-007) where the modules were being used and end up with an eventual Unsupported SA due to know vulnerability.

Unfortunately the above is also countered by the fact we don't want someone adopting a module namespace that was security covered and using it to exploit the ecosystem.

Perhaps this should be a must remove security coverage and flag it with a warning/control that requires the Project Ownership Queue to only allow adoption by a vetted user?

Perhaps this should be a must remove security coverage and flag it with a warning/control that requires the Project Ownership Queue to only allow adoption by a vetted user?

That makes 100% sense to me. The security advisory opt-in is, more or less, a social contract with the security team. If there's not a body to uphold that half of the contract, it's effectively null and void.

This is a fantastic idea and I really appreciate all the guard rails listed in the proposal.

-mike

This demonstrates thorough consideration. I would like to express my willingness to nominate myself for inclusion in the group and contribute to the remaining D10 update tasks as well as the upcoming D11. My sincere appreciation goes out to all those who were involved in crafting the proposal.

I was hoping that we could allow an opt-out option for projects, everyone opted-in automatically, for rector automatic updates to code.
Any project that has not opted-out would automatically get the rector commits and a rector release for the deprecation fixes and compatibility release.
With the trend towards AI, we should leverage AI when possible to make things easier for us.

Makes sense, thoughts:

* The timing/time span is not entirely clear to me. From start of an issue to commit, how much time is that now exactly? 2 weeks? 4 weeks? Either way, that seems fairly short time, it's not uncommon that people have some extended off time for 2-4 weeks and be unreachable for that. I don't think we need to hurry a lot, we start with those rector issues pretty early while a new major version is still being developed and have months until a project is at risk to block people from upgrading. So maybe that should be extended a bit and/or there should be some consideration to the major release schedule.

* #12 has some valid concerns on letting modules die out, I agree that we should weigh possible alternatives and maybe also usage numbers, to avoid getting overwhelmed with projects that only have a handful of installs. That said, Drupal modules tend to be much harder to replace than a pure PHP library, where you just have to adjust some code, maybe even only a new use statement. Drupal modules have a blocking namespace, and switching requires installing a new module in parallel, possibly migrating configuration and even data over multiple stages/deployment. So we might want to update such outdated/replaced modules too in some/many cases, so that sites can stay on a supported core version and have time to consider those alternatives. To add to the first point, those conditions should probably not just be used to decide if this working group steps in, but also when. These kind of modules could be put in a queue to revisit again closer to EOL of a major version?

* Not sure on security impact. AFAIK, we currently don't even support reverting modules to a non-security-covered state. This is currently not even possible as a non-security team member, I can't opt-out once I opted in on the project page. We AFAIK only do that if there are known security issues and also fully mark a module as unsupported/unsecure then. That would IMHO also kind of defeat the purpose then, without security support, you can just as well switch to an inofficial fork somewhere.

PS: Re #16, that has nothing to do with this proposal and just no for so many reasons. Rector has nothing to do with AI (and if it had that would be more reasons to not do that, not less) and tools like rector and phpstan always need manual reviews and considering, the number of problems and incorrect changes in rector patches is still quite high, and even just phpstan flagged "problems" that are manually fixed can cause regressions, most recent example: 🐛 Exposed filter values ignored when using batch Needs work .

@Berdir
I acknowledge that the rector has made mistakes, however it works far more often than it fails. Perhaps a moderated rector where a press button approach is all it takes is for two humans to approve and given a specific criteria the change is made automatically even if those two humans are not maintainers. This could be an opt-out option for projects. Projects with active maintainers could easily opt-out.
I'd rather a few mistakes be made than to have to wait weeks chasing down inactive maintainers waiting for their response.

This is great - thank you very much !

Excellent proposal. If it is accepted I will nominate myself to the working group.

A big +1 for me as well.

One thing I should point out about the proposal is that it stipulates that the current maintainer MUST be contacted twice through their drupal.org contact form. Users can opt out of that form being available, however, so the proposal should include an indication of how it will be handled if the contact form is not an option. I suspect that a DM in Slack would be the next best option, but not all users have joined Slack, and there isn't always a 1:1 correlation of usernames.

Read The RFC +1 from me too for idea and formation of working group.
I have few suggestion over handling the case where if the maintainers do not respond even after trying to reach out by the working group member, can we mark such releases as updated by community or something similar.

Thank you

The contact form is always accessible from user administrators, even when it has been disabled by unchecking Personal contact form. (Allow other users to contact you via a personal contact form which keeps your e-mail address hidden. Note that some privileged users such as site administrators are still able to contact you even if you choose to disable this feature.)

I think it's a good idea, specifically because the conditions for using their access to become a temporary maintainer are strict, and the access is narrow and focused specifically to the automated issue and its patched.

I reread the comments and there is strong support for this proposal.

This is the list the points I found that still need to be addressed. None of these are blockers to this proposal. Many will be resolved as the group starts to work. And work on the one about confusion in contrib about semver could begin work now, it does not need this working group to do that.

1. #4 "Should the working group tag a release off HEAD or cherry pick the fix for a smaller change set?"
2. #5 Add a regular review step
3. #6 "How are we considering a maintainer is not active?"
4. #9 Security. "Is there a communication that should come from the security team regarding a change to the advisory coverage"
5. #12, #13 Security. "Perhaps this should be a must remove security coverage and flag it with a warning/control that requires the Project Ownership Queue to only allow adoption by a vetted user?"
6. #12, #17 Accept 'natural attention'. Put 'serious weight to 6.5'.
7. #12 additions to policy - see #12
8. #12 What about modules that are using 'registered trademarks'?
9. #12. Semver in contrib. "I would suggest defining these parameters explicitly as they relate to the Working Group. There is already a decent amount of contention inside of Contrib as to what is a semver breaking change and what is not. It would likely save the working group a significant amount of time if their policy was standardized."
10. #17 What is the time span from start to finish?

Therefor, I am setting this to RTBC.

And here is the issue about semver in contrib I was thinking about when I wrote the above. 📌 [pp-1] Document best practices for Drupal core support and semver for contributed project mainteinrs Active

I'm also +1 on this proposal. It's a fantastic idea, and the proposal feels very robust.

I also agree with @quietone in #25 that the unaddressed points are non-blockers that can be worked out by the group itself.

Great job! Thank you for your efforts. I'd say: let's go ahead with it.

Opened a merge request to add the charter for this https://git.drupalcode.org/project/governance/-/merge_requests/19

I've based it off the initial request for comment and the format of existing charters.

Once that's approved/merged - I'll take the following actions:

I've also added a stub project at /project/puwg so the charter has valid links.

• Create new issues in this queue for the items in #25
• Create a public and private slack channel for the group.
• Add a new 'Membership applications' component to the PUWG project issue queue
• Create a new core blog post calling for initial members
• Flesh out the PUWG project page

If you want to review the rendered markdown https://git.drupalcode.org/project/governance/-/blob/fa2f41e7e620d17077d...

Noticed one minor typo in MR, left a comment there.

Otherwise +1 from me, it is good to see this moving forward!

All the changes to the MR in the last two weeks were improvements, such as wording, adding links, and grammar. None of the changed altered the intent or workflow of the new 'Project Update Working Group'.

Therefore, I am restoring the RTBC.

I also reviewed both the resulting charter and the changes since Dries' approval in #27 and all looks good. I agree the changes are clarifications and minor wording changes as well as typo fixes. They don't change the processes or actors or any significant part of the proposal.

Landed this! One thing I noticed after merging it is that the main page links and figure was not updated with the PUWG, but we can do that in parallel to other activity about it! Thanks everyone!

Thanks, everyone! I found some minor typos and formatting inconsistencies so have created an MR here:

#3424528: Typos in Project Update Working Group Charter. →

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