Offering to co-maintain Cloudflare Stream

The procedure for Dealing with unsupported (abandoned) projects says:

When opening an issue for a project that has opted into security coverage, you must explicitly say in the issue summary if you have that permission. If you aren't sure about having that permission, write that in the issue summary.

That information is missing in the issue summary. Postponing until that has been cleared up.

pjbaert doesn't have the vetted role. pjbaert should get that role, or the project owner should add pjbaert as new co-maintainer.
This issue should be postponed until then.

I assume you mean that it will be postponed until pjbaert gets the vetted role, or the project owner or one of maintainers adds pjbaert as a new co-maintainer.

If so, I agree.

I have the vetted role. Feel free to assign the project to me and I will add PJ to the project and review the code that he pushes to Drupal.org.

He's got 21 commits, he's been working on an abandoned module. He's following the procedure for abandoned modules. He works for a respected company.

Do you remember how most of us got the vetted status? A random person ticked a box to give me maintainer status on a tiny module. I had 0 commits.

@Greg Boggs We don't add as maintainer a user just to let that user add as co-maintainer a user who doesn't have the vetted role.

In the past, the vetted role didn't exist. When it was introduced, it was given to the users who had the permission to commit code on drupal.org repositories. Nowadays, users don't need to ask for the permission to commit code on drupal.org repositories, as that is automatically given when they enter a Git username and they accept the Git access agreement, but they need to apply to get the vetted role.
What done in the past doesn't change what is done nowadays.

Greg Boggs wrote:

I have the vetted role. Feel free to assign the project to me and I will add PJ to the project and review the code that he pushes to Drupal.org.

kiamlaluno wrote,

@Greg Boggs We don't add as maintainer a user just to let that user add as co-maintainer a user who doesn't have the vetted role.

That is not a correct summary of what he says he intends to do. He also says he'll: "review the code that he pushes to Drupal.org".

I.e. he is willing to take the same responsibility of any project owner that adds a non-vetted maintainer: Provide security oversight of the code that is committed to the repo by the co-maintainer.

Greg Boggs: However, if you are willing to do this, please follow the exact procedure outlined in: https://www.drupal.org/node/251466#procedure---own-project

(I.e. open up and issue in project's issue queue to request ownership, send PMs to the two maintainers that have their contact form enabled, wait 14 days, move the issue here, and we'll deal with it in a timely manner.)

And you're probably now thinking: Why all this red tape. Why can't he just take my offer to maintain from comment #8 and make this abandoned project maintained again - right here and now?

I'll try to explain: A Drupal.org webmaster overriding a owner or a maintainer and assigning a new owner or adding a maintainer to an existing project may be a sensitive matter. Thankfully, most owners here just want to see their projects well maintained, and would not mind. But there are some project owners that consider such an override by a webmaster as a violation of their copyright and appropriation of their hard work.

So, the established procedure of the webmasters that handle these issues is to follow the protocol exactly as it is spelled out. I am the first to admit that this is inflexible and even annoying, but it ensures consistency in our responses, and it also safeguards against accusations about due process not being observed.

Greg Boggs wrote:

Do you remember how most of us got the vetted status? A random person ticked a box to give me maintainer status on a tiny module. I had 0 commits.

Yes, I agree that the current vetting process is no longer useful. A very long time go, the vetting process actually provided a meaningful onboarding experience. But that approach that did not scale well. It became slow as molasses, creating an extremely frustrating experience for our contributors. I understand that it has been revamped since then, and is much faster these days. But it seems to be all about coding standards, not ability to write secure code.

Some people has suggested to replace the project review peer process with a quiz: #1290624: Develop quiz to put in front of the opt into security coverage checkbox - but that initiative seems to be dead in the water.

The requirement for the having the vetted role for being added as a maintainer or co-maintainer by the webmasters if the project had opted into security coverage originated with the security team. The webmasters did not make this rule. However, the Drupal.org webmasters have to enforce community rules, whether we agree with them or not.

My comment was referring to Feel free to assign the project to me and I will add PJ to the project.
We don't add as maintainer a user who isn't a co-maintainer of a project to let that user add another user, who is willing to commit code, as co-maintainer, especially in the case the user willing to be co-maintainer doesn't have the requirements to be added as co-maintainer from webmasters. The fact the first user will review the code committed from the second user is irrelevant, as we don't even add as maintainer a user to let him add another user, who is willing to commit code, as co-maintainer and review the code that user will commit.

I stand correct, as every request to be added as maintainer to be able to add a co-maintainer will be declined, especially if the request comes from a user who isn't co-maintainer of the project.

every request to be added as maintainer to be able to add a co-maintainer will be declined, especially if the request comes from a user who isn't co-maintainer of the project.

I agree. We can't act upon that request.

So instead I suggested to Greg Boggs that he goes through the full formal procedure for taking over an abandoned project, exactly as outlined in https://www.drupal.org/node/251466#procedure---own-project

I.e., I always to try to make an effort to describe to our community members offering to contribute what is possible within the existing rule set, instead of limiting the discourse to stating just what cannot be done.

Clearly the maintainer support team being able to team work on project recovery is within the spirit of the guidelines. But, I can see why you don't agree, because it's unusual for the community to work as a team to recover dead projects. So, I'll work on the improving the guidelines and I will do your requested work just so you feel comfortable that we're following the procedure correctly.

Hello Greg,

I am current project maintainer. I added both you and pjbaert as co-maintainers.

Great, tamerzg! Thank you so much for getting this issue resolved.

We always prefer co-maintainer offers to be sorted out by the project's own maintainers, rather than by overrides by the webmasters.