🇮🇹Italy @apaderno

I added zaporylie as maintainer, since the project is not covered by the security advisory policy.

The issue needs to stay in the project issue queue for at least two weeks, with a title that includes the project name, to allow the interested people to see the issue in the global tracker.

These offers need to be first opened in the project issue queue.

I added the feed to Planet Drupal ( https://www.drupal.org/aggregator/sources/2083 → ).

Still, there are no commits from gautam_105@, nor there is a branch with commits just from gautam_105@.

I will repeat it: These applications are not for projects, but for people (one person per application) who need the permission to opt projects into security advisory coverage.
They are not projects for all the project maintainers. As such, we do not review what the projects maintainers as group understand about writing secure code that follows the Drupal coding standards and correctly uses the Drupal API.

If gautam_105@ wants to be able to opt projects into security advisory policy, he needs to provide a project where all the commits have been done by him.

Let's start over: The issue title needs to contain the project name and the issue needs to explicitly say which role is asked.

All the commits have been done by whitedevil, who eventually should be the person who applies using that project.

Just as a reminder: These applications are not done for a project; they are done for a person, to whom will be given a new drupal.org role which allows that person to opt projects into security advisory policy. That is not a role we give to every maintainer, but only to the person who created the application, who must be the person who done the commits in the project used for the application.

Now that patches are no longer tested, the issue should provide a merge request.

The changes are just for using the short syntax for array and adding a @var line for a property declaration.

IMO, they are so small that they should be fixed when fixing other issues in the code, if those issues are present. Otherwise, the merge request in this issue can be merged, at project maintainers' discretion.

avpaderno → changed the visibility of the branch 3477518-fix-the-phpcodesniffer-issues to hidden.

avpaderno → changed the visibility of the branch 3034265-fix-the-errorswarnings to hidden.

The 8.x-1.x branch is no longer supported; any change needs to be done in the 2.x branch.

Core Theme Candidate Requirements seems really outdated: It says the theme needs to support overlay and it must pass XHTML 1.0 Strict validation. If that overlay means the overlay Drupal 7 implements, that is no longer implemented in Drupal 8+.

I would think that Core Theme Candidate Requirements can be deleted, if it cannot be rewritten in Drupal 11 requirements.

I published the posts/comments that were unpublished.

I am crediting the person who confirmed the account.

No post/comment needs to be published.

These offers need to be moved from the person who created them. If the person is no longer interested, moving the request in the Drupal.org project ownership queue is pointless.

This is the markup I used in the new revision.

This is the main project for all <a href="http://drupal.org/documentation">Drupal documentation</a>, except contributed projects. For contributed projects create an issue in the issue queue for that project.

To learn more about helping with documentation efforts, start with the <a href="http://drupal.org/contribute/documentation">Contribute to documentation</a> section of the handbook.

<p>You can report issues regarding documentation in the following places:</p>

<h3>About the documentation "infrastructure" (software tools for creating, editing, maintaining, locating, and reading the documentation on Drupal.org)</h3>
<p>Create an issue in the <a href="http://drupal.org/node/add/project-issue/documentation" rel="nofollow">Documentation project issue queue</a> and use the <strong>Docs infrastructure</strong> component.</p>

<h3>About documentation procedures and policies</h3>
<p>Create an issue in the <a href="http://drupal.org/node/add/project-issue/documentation" rel="nofollow">Documentation project issue queue</a> and use the <strong>Policies and Procedures</strong> component.</p>

<h3>API (api.drupal.org)</h3>
<p>Create an issue in the <a href="http://drupal.org/node/add/project-issue/drupal" rel="nofollow">Drupal Core project issue queue</a> and use the <strong>documentation</strong> component. The only exception is a few files, such as the Form API reference, which are actually here in the Documentation git repository.</p>

<h3>User interface text within Drupal core itself</h3>
<p>Create an issue in the <a href="http://drupal.org/node/add/project-issue/drupal" rel="nofollow">Drupal Core project issue queue</a> and use the <strong>user interface text</strong> component.</p>

<h3>Contributed project</h3>
<p>Create an issue in the issue queue for that project.</p>

<h3>Spam</h3>
<p>Use the <em>report spam</em> link shown for comments and nodes.</p>

<h3>For any other issue with the Drupal.org online Community Documentation</h3>
<p>Create an issue in the <a href="http://drupal.org/node/add/project-issue/documentation" rel="nofollow">Documentation project issue queue</a> or, better yet, just edit the page.</p>

Or, did I miss something?

You did not. I was just saying this issue should have been only for the documentation guide from the beginning. If the download page were not changed, that part should have been a different issue in the correct queue.

MR!4 was created just to get the list of the errors/warnings to fix.

avpaderno → changed the visibility of the branch 3476322-gitlab-ci-reports to hidden.

The issue summary still needs to be updated, since it does not show what GitLAb CI reports, nor give a link to the GitLab CI report.

There are no PHP_CodeSniffer errors/warnings to be fixed.

The issue summary needs to link to the PHP_CodeSniffer report done before changing the project files, not after.

The issue summary must still be updated.

I added dillix as maintainer.

QuickStart probably does not give issues when using a Linux distribution with the most recent packages.
I used Ubuntu 24.10 and I had no problems because that and because I had already all the required packages installed. For somebody who wants to just test Drupal, DDEV is probably the easier solution, assuming DDEV is already used as development tool.

avpaderno → made their first commit to this issue’s fork.

I apologize: I saw the comments on the merge request, but I was not able to find this issue when I was ready to change the merge request.

Probably that part should be changed to suggest adding a comment on 🌱 Recruiting guide maintainers for documentation Active or asking on Slack.
Site moderators can administer most of the documentation guides; a comment in that issue or a post on Slack should do the task.

but it works well for you browsing for several minutes?

I kept going from page to page for some minutes; I then waited some minutes and started again to browse the site. It did not stop to respond.
I could make a more intensive test after dinner.

This is the message I sent to iaugur.

Hello George,

I am contacting you because Juraj ( https://www.drupal.org/u/poker10 → ) offered to become co-maintainer for Commerce Stock ( https://www.drupal.org/project/commerce_stock → ), a project for which you are maintainer.

May you post a comment on https://www.drupal.org/project/projectownership/issues/3490839 💬 Offering to co-maintain Commerce Stock Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Juraj will be probably made co-maintainer.

Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.

I am contacting all the people who can administer co-maintainers/maintainers for the project.

As last note: This offer is about being co-maintainer, which for us means somebody who does not have all the drupal.org permissions on the project. Even though being co-maintainers could mean having just a single permission, we expect a co-maintainer to have the following permissions on the project: Write to VCS, Edit project, Maintain issues, Administer releases.
If there is any reason for not giving Juraj all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3490839 💬 Offering to co-maintain Commerce Stock Active .

Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator

This is the message I sent to guy_schneerson.

Hello Guy,

I am contacting you because Juraj ( https://www.drupal.org/u/poker10 → ) offered to become co-maintainer for Commerce Stock ( https://www.drupal.org/project/commerce_stock → ), a project for which you are project owner and maintainer.

May you post a comment on https://www.drupal.org/project/projectownership/issues/3490839 💬 Offering to co-maintain Commerce Stock Active about accepting or declining the offer? Please do not reply via email; we need a reply on the offer issue.
Without a comment posted on that issue in the next 14 days, Juraj will be probably made co-maintainer.

Project moderators will not remove the existing maintainers/co-maintainers; the project owner will not be replaced either. Maintainers cannot change the project owner; co-maintainers/maintainers can only be removed/added by people who have the permission to administer co-maintainers/maintainers.

I am contacting all the people who can administer co-maintainers/maintainers for the project.

As last note: This offer is about being co-maintainer, which for us means somebody who does not have all the drupal.org permissions on the project. Even though being co-maintainers could mean having just a single permission, we expect a co-maintainer to have the following permissions on the project: Write to VCS, Edit project, Maintain issues, Administer releases.
If there is any reason for not giving Juraj all those permissions, please explain that on https://www.drupal.org/project/projectownership/issues/3490839 💬 Offering to co-maintain Commerce Stock Active .

Best regards,
Alberto Paderno
-- Drupal.org project moderator
-- Drupal.org site moderator

I am going to send the second message in few minutes.

The status has been changed because we are waiting for a reply.
Please post a comment after 14 days, if your offer has not been declined. It will show you are still interested in maintaining this project and it will serve as reminder an action is required for this offer.

mkdir drupal && cd drupal && curl -sSL https://www.drupal.org/download-latest/tar.gz | tar -xz --strip-components=1 and php -d memory_limit=256M ./core/scripts/drupal quick-start demo_umami worked for me. They installed Drupal 11.0.9 with the Demo: Umami Food Magazine installation profile, which I was able to test.

Simplytest.me works for me, with Drupal 10. It does not work when I click on the Starshot button.

The maintainers are guy_schneerson → and iaugur → . They both logged in at least once in the past seven days.

I will contact the project maintainers in the next two hours.

Furthermore, since patches are no longer tested, a merge request is now requested.

The issue summary is still empty.

Remember to change status, when the project is ready to be reviewed. In this queue, projects are only reviewed when the status is Needs review.

Thank you for applying!

Please read Review process for security advisory coverage: What to expect → for more details and Security advisory coverage application checklist → to understand what reviewers look for. Tips for ensuring a smooth review → gives some hints for a smoother review.

The important notes are the following.

• If you have not done it yet, you should enable GitLab CI for the project and fix the PHP_CodeSniffer errors/warnings it reports.
• For the time this application is open, only your commits are allowed.
• The purpose of this application is giving you a new drupal.org role that allows you to opt projects into security advisory coverage, either projects you already created, or projects you will create. The project status will not be changed by this application; once this application is closed, you will be able to change the project status from Not covered to Opt into security advisory coverage. This is possible only 14 days after the project is created.
  Keep in mind that once the project is opted into security advisory coverage, only Security Team members may change coverage.
• Only the person who created the application will get the permission to opt projects into security advisory coverage. No other person will get the same permission from the same application; that applies also to co-maintainers/maintainers of the project used for the application.
• We only accept an application per user. If you change your mind about the project to use for this application, or it is necessary to use a different project for the application, please update the issue summary with the link to the correct project and the issue title with the project name and the branch to review.

To the reviewers

Please read How to review security advisory coverage applications → , Application workflow → , What to cover in an application review → , and Tools to use for reviews → .

The important notes are the following.

• It is preferable to wait for a project moderator before posting the first comment on newly created applications. Project moderators will do some preliminary checks that are necessary before any change on the project files is suggested.
• Reviewers should show the output of a CLI tool → only once per application.
• It may be best to have the applicant fix things before further review.

For new reviewers, I would also suggest to first read In which way the issue queue for coverage applications is different from other project queues → .

I would just avoid adding "or the Report as spammer link shown in user profiles" because in most of the cases what needs to be reported is a post or a comment, for which the Report as spammer link does not help much. It just adds a link to the user account in a view; site moderators then need to check all the comments or posts created using that account to find what needs to be deleted as spam.

I find the project page as proposed more readable. The list made probably more sense when the list items were fewer → , and they did not appear as a wall of text like now.

I changed the project description as suggested in the issue summary.

(I made a sentence I wrote clearer.)

Furthermore, the download page is not a documentation page that can be edited by somebody who has the community role. It is content that can only be edited from few people (probably who have the Association staff role).

I would use this issue only for the documentation page.

avpaderno → made their first commit to this issue’s fork.

Since GitLab CI is enabled for all the projects, it should be used to get the list of the PHP_CodeSniffer warnings/errors to fix.