Update “How to become project owner…” to reflect security opt in permission is optional.

The verb will does not indicate certainty, and it does not surely mean at free will.
There is no need to make that sentence clearer, or similar documentation pages using will (the verb) should be changed too.

If there is dispute on if the 2nd sentence needs to be adjusted I suggest we focus this issue solely on the first sentence as it can be changed independently in order to avoid this issue being derailed.

Updated IS.

@avpaderno has updated the relevant section to read

Project moderators will not add as owner, maintainer, or co-maintainer a person who cannot opt projects into security advisory coverage, when a project is covered by Drupal's security advisory policy. In that case, the request needs to be accepted by a project maintainer, including the project owner, or a project co-maintainer with the Administer maintainers permission.

It would be nice to have clarification on what this is suppose to mean so that we can refer to it in the future.

Scenario 1:
A user does not have the security opt in permission and applies to a module that is opted in to the security advsiroy program. The module has a stable release that supports a currently supported version of Drupal Core, neither the project maintainer nor a user with "administer maintainers permissions" on that module responds with consent.

Scenario 2:
A user does not have the security opt in permission and applies to a module that is opted in to the security advisory program. The module does not stable release for a currently supported version of Drupal core (it may have a stable release for a prior version of core, such as D10.1 when core only supports D10.3+), neither the project maintainer nor a user with "administer maintainers permissions" on that module responds with consent.

For each example scenario above: can moderators add the user to the module?

I think I have already said this, but let's make it clearer: How to become project owner, maintainer, or co-maintainer is not a policy. It is a documentation page written by project moderators to describe what they do when handling those offers/requests. In the specific, it is a documentation page that describes the process to people who make the offer/request.
The purpose of that documentation guide is not making a policy. It is describing the process to make it handled similarly by all the project moderators and avoid, for example, that a project moderator adds a new maintainer/co-maintainer directly, without contacting the project maintainers, simply because the contact tab is only accessible to people with the permission to administer user accounts.

Given that, may you point out to any policy that says that being able to opt projects into security advisory coverage is optional? Because, otherwise, what described in the title is just a personal interpretation which could not match the interpretation of people who handle those offers/requests.

is not a policy. It is a documentation page written by

According to @hestenet (CTO of D.A.) it is the closest to a canonical document we have on the subject. See https://drupal.slack.com/archives/C5ABFBZ5Z/p1746562497353509?thread_ts=...

I’ve accepted it isn’t a policy document, that in my mind doesn’t mean we can’t update it to show edge cases to better align to policy (whatever it is) so that applicants are better aware of when they apply vs when they can’t.

may you point out to any policy that says that being able to opt projects into security advisory coverage is optional?

As I have never been provided a document I am compelled to go by statements and actions of Project Ownership queue admins on D.O. and Slack. Perhaps some of this is misunderstanding of edge cases hence the question from comment #4.

For examples:
An ownership queue admin in 📌 Request to assume module maintenance Active transferred a project enrolled in the Drupal Security Advisory program to a user that does not have the security opt in privilege. Either an error was made, or there isn’t a policy prohibiting transfer of enrolled projects.

In #345233: Parent Menu Collapases on Panel Page → I said Linking two issues where a Project Ownership Queue Admin transferred projects that were opted in to Security Coverage to a user who did not appear to have the opt in permission required per policy. and was told by a project ownership queue admin the document discussed in this issue is not a policy and to Please stop making false claims.. If such a policy existed prohibiting such a transfer there would be no to call out “false claims” of a policy existing.

In #345233: Parent Menu Collapases on Panel Page → I quoted a project ownership queue admin as saying Project moderators will not add as co-maintainers/maintainers people who cannot opt projects into security advisory coverage and in response was told

 In English, will does not mean certainty.
That part means people who cannot opt projects into security advisory policy cannot expect to be added as maintainer, co-maintainer, or project owners. It does not mean a project moderator will not add them as maintainers, co-maintainers, or project owners

. It is always possible the individual was just trying to provide an English lesson rather than answer questions , however unless they indicate as such I have to presume they were attempting to be collaborative in helping correct a misunderstanding of how project ownership queue admins can process requests and inform me that my suggestion to automate requiring a user has the permission if the project enrolled should not be implemented as it is not policy.

Should have set back to active after providing feedback that
Policy “is optional” is based on actions and statements of Project Ownership admins.

Yet, it is not a policy. The phrases used are fine for that type of documentation guide.

Notice that being able to opt projects into security advisory coverage is optional means being able to opt projects into security advisory coverage is always optional, which is not true at all.

The modal verb will has been always in such phrases. I guess nobody would complain about using I will come to live in Italy. saying the sentence must make clear that coming to live in Italy is optional.

Only legal documents make clear what the documents means with shall and will.
That documentation guide is not at that level. It is a documentation guide written for project moderators to make sure the followed procedure is the same for every project moderator and avoid that (for example) in a case the project maintainers are not contacted simply because the contact form has not been made public, while in another case even people who do not have the Administer maintainers permissions are contacted.

It is a documentation guide written for project moderators to make sure the followed procedure is the same for every project

This is not a Site Moderator only guide. It is also used by the community by applicants to understand when and how they can apply.

This page lineage can be tracked to the "Getting involved - Dealing with unsupported (abandoned) projects " which was intended for community members. An archived copy can be seen at https://web.archive.org/web/20170717080153/https://www.drupal.org/node/2.... That node was deleted (twice) in 2022 by @avpaderno when they moved the page to its new location, see 🐛 Taking over unsupported abandoned projects has gone away Needs review for incident information.

for project moderators to make sure the followed procedure is the same for every project

If it does not cover all scenarios how can it ensure that the procedure is the same for every project?

I am asking for the documentation to be updated to include the scenario that occurred in 📌 Request to assume module maintenance Active that a user without the opt in permission was able to be added to a project that was already enrolled in the security advisory policy. That way a user without the permission knows there is a chance they they can be approved (although not required to be approved) (or if that application wasn't suppose to be approved it would be wise for the project ownership queue to cleanup the issue).

As an aside since the contention on "will" is a large part of our discussion (I suspect English as a Second Langue is involved here):

I guess nobody would complain about using I will come to live in Italy. saying the sentence must make clear that coming to live in Italy is optional.

You have used this in the past to explain will as 'optional' however in this sentence I would contend the normal interpreted to mean the person writing the statement saying that in the future (either as wish/desire/goal or known truth) their home shall be Italy. Traditionally in this phrasing it is intended to indicate a future certainty. If there is no certainty it would be written "I want to live in Italy" to express the desire without the intention to ensure it occurs (not a life goal).

Traditionally in this phrasing it is intended to indicate a future certainty.

No, the modal will is not just used for future certainty. Basing on the Merriam-Webster it is:

• used to express futurity
• used to express desire, choice, willingness, consent, or in negative constructions refusal
• used to express a command, exhortation, or injunction
• used to express frequent, customary, or habitual action or natural tendency or disposition
• used to express probability and often equivalent to the simple verb
• used to express inevitability
• used to express determination, insistence, persistence, or willfulness
• used to express capability or sufficiency

In any case, none of the sentences used in that documentation page means that being able to opt projects into security advisory coverage is always optional, nor they could be interpreted that way. Therefore, the premises for this issue are wrong.