Create process for adopting contributed projects for Drupal 10 readiness

Resources have been added here:

https://docs.google.com/spreadsheets/d/1jUv6jkLM9u49hqCcgf-4W9bIEKEhsfJ-...

Added to spreadsheet and copied below. Marking fixed for now but we can tune this and we can add steps for projects that have a compatible dev branch.

Process for co-maintaining projects without compatible dev branch

1. Review projects in Projects tab
2. Find a project where you know how to test the module/theme
3. Verify the project does not already have pending co-maintainer issues
4. Check the issue queue for Drupal 10 compatibility issues
5. Check the dev branch to see if it is already D10 compatible
6. If you want to co-maintain, comment on the Projects tab for that project in the "Who to adopt?" column (alternatively, DM Kristen Pol for edit access)
7. Create an issue to offer to co-maintain (example)
8. Contact the project maintainer via Drupal.org if possible (needs contact tab enabled)
9. Add comment to the issue that you have contacted the maintainer or you couldn't because the tab was missing
10. You have to give the maintainer 14 days to respond
11. After 14 days, if there is no response, you can move the issue into the projectownership queue
12. If co-maintainership is granted or is not granted, add a comment on the Projects tab
13. If granted, provide issue credit to those involved on the issue to offer to co-maintain
14. Go through all Drupal 10 compatibility issues and review/test as appropriate and update issue credit as appropriate
15. Once all D10 issues are ready, merge into the appropriate dev branch (be careful if there are multiple branches that you are using the correct one; ask in #d10readiness if you aren't sure)
16. Mark all merged issues as Fixed and verify issue credit is correct (make sure to give yourself credit for this work; you can also give credit manually to anyone who helped you offline in the Slack channel)
17. (Optional) Review the RTBC issues and review/assess/test each as appropriate to merge what you can (make sure to give issue credit as appropriate)
18. If you don't have access to create releases, create an issue for the maintainer to create a release (need example)
19. If you have access to create releases, determine the release number to use (if in doubt, ping us in Drupal #d10readiness Slack)
20. Create a tag with that version
21. Through the project page, click "Add new release" and choose the new tag and add descriptive text
22. Through the project page, click "Administer releases" and adjust as appropriate (if in doubt, ping us in the Drupal #d10readiness Slack)
23. Add comment on the Projects tab with the status
24. Ping us in the #d10readiness channel so we can celebrate your win!

Resources

Slack thread on project suggestions
Slack thread for soliciting volunteers
How to become project owner, maintainer, or co-maintainer →
Old abandoned project process page is missing but is archived 🐛 Taking over unsupported abandoned projects has gone away Postponed: needs info
Co-maintaining projects →

Feedback is still welcome here or as a comment in the spreadsheet or via the Slack thread.

Step 8/9 should probably call out in more detail what should be done.

I’m seeing messages that simply say “contacted the maintainer” and some that show no indication of contacting the maintainer.

From the abandoned module process:

If enabled, use the Contact tab on the owner profile page to contact the project owner, asking to post a comment on the issue you posted. We need a comment on the issue you opened to make the decision of the project owner publicly visible.

Put a record of the attempts to make contact in the issue summary, spelling out who, when, and how. This information is helpful when site moderators decide whether to act immediately or make further attempts to contact the maintainers.

A key aspect to the process is that the module owner is made aware that if they do not respond the site moderators may take action and assign permissions to a user. It is the obligation of the individual applying for ownership to demonstrate the maintainer has been given an opportunity to respond otherwise the project ownership queue needs to reach out themselves and delay the application.

Remember adopting a module is essentially a supply chain attack and should always be subject to strict scrutiny.

I recommend the posting detailing the initial attempt to reach out to the project owner contains to who, how, /and when an attempt was made, a copy of the message sent and the message sent itself contains at least a link to the issue and the key phrase “site moderators may assign the to my account if no response is received on the linked issue within 14 days.”

Messages that do not include the notice that the moderators may take action are “friendly offers” and do not necessarily start the 14 day time counter.

Other methods of contact to consider:
Email address from commit logs.
Twitter/Slack/other messaging services.

The more a volunteer can prove they attempted to reach the maintainer the more likely an issue will clear the moderators.

We are trying to be more sensitive with our wording as not all projects have been "abandoned"... some maintainers simply don't have time due to a number of reasons and could use some help.

I updated the process to link off to comment #5 for details on contacting the maintainer and documenting it. Thanks @cmlara :)

I also noted that you have to have permission to opt into security coverage in order for the project ownership to be switched by a non-maintainer (i.e. in the projectownership queue).

Marking fixed for now but we can continue to tweak as needed.

Crossing off task.

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