Address ethical concerns in "How to become project owner, maintainer, or co-maintainer"

The "Things you do not have to worry about" section does not address the ethical concerns of committing a social engineering and supply chain attack to inject oneself as a new owner.

It does not contain anything about that topic because that is not the purpose of that section.
The parts in that section can be rewritten as follows.

• I want to be maintainer/co-maintainer of a project, but I do not like how it is written, and I do not want to learn the old code.
• I want to be maintainer/co-maintainer of a project, but I do not want to support existing users.
• I want to be maintainer/co-maintainer of a project, but I do not want to be associated with a failed project.

If what added in that section, can be rephrased like that, it does not probably belong to that section.

Also, the ethical concerns of committing a social engineering and supply chain attack to inject oneself as a new owner is a topic relevant for everybody who is a project maintainer, independently from being added as project maintainer by following Offering to become a project owner, maintainer, or co-maintainer.
That seems more a topic for Managing a drupal.org theme, module, or distribution project → .

Possible phrasings to answer the topic:

I want to be maintainer/co-maintainer of a project, but I do not want to risk my future employability by performing a supply chain attack.

I want to be maintainer/co-maintainer of a project, but I do not want to commit a supply chain attack.

I want to be maintainer/co-maintainer of a project, but isn’t this processes a supply chain attack.

I want to be maintainer/co-maintainer of a project, but do not want to steal from other members of the community.

I want to be maintainer/co-maintainer of a project, but I do not want to be considered unethical by security focused community members.

I’m pretty sure you see where this is going, it is possible to fit in to that section.

engineering and supply chain attack to inject oneself as a new owner is a topic relevant for everybody who is a project maintainer, independently from being added as project maintainer

True, though it is equally relevant in that section as well. Perhaps it needs content in two places.

I want to be maintainer/co-maintainer of a project, but I do not want to be considered unethical by security focused community members.

There is enough to write on the subject that four lines could not be enough for a summary.
I cannot even say that being considered unethical by security focused community members is one of the reasons for which people do not ask to being maintainer/co-maintainer of an existing project and they instead create their own project. Differently, the other points in that section are effectively reasons for which somebody did not want to be maintainer, or for which somebody was considering not to offer to be maintainer/co-maintainer.

The "Things you do not have to worry about" section is intended to convince D.O. users to adopt a project rather than forking or otherwise creating a new project. Convincing prospective adopters that adopting is ethical to avoid a fork aligns with that sections responsibility.

I cannot even say that being considered unethical by security focused community members is one of the reasons for which people do not ask to being maintainer/co-maintainer of an existing project and they instead create their own project.

I was added via the shortened adoption process in #3237307: Offering to maintain RabbitMQ → to a module.

At the time I took these policy as "its in the ecosystem, everyone agrees with it". It was certainly not my first concern at the time. As I have become more involved in the community and seen its apathy to secure practices I find myself questioning that logic.

Since the time of the application a maintainer returned and since disappeared again. During that time they raised questions about design and future plans. This has lead to a stall in development (including lack of D11 support) while the moral and ethical concerns are being evaluated with the potential of a fork being required as I question if I have the ethical authority to continue development.

As noted above the "Things you do not have to worry about" section is responsible to assuage those concerns.

There is enough to write on the subject that four lines could not be enough for a summary.

That is fair point, and why the section may need to refer to reference material in other sections.

That is fair point, and why the section may need to refer to reference material in other sections.

Probably, that needs to be written in a different documentation guide.

Still, I have to see in which way offering to be maintainer/co-maintainer would be considered unethical.
What could be considered unethical is what the person who has been added as maintainer/co-maintainer can do after being added as maintainer/co-maintainer. That is not different from what is considered unethical when done from a project owner.

Truly, the full Things you do not have to worry about section seems out of place: People who read How to become project owner, maintainer, or co-maintainer already have the intention to be maintainer, co-maintainer, or project owner. If somebody would not want to be associated with a failed project, for example, they would not ask to be co-maintainers/maintainers, nor project owners. They would not even provide patches or create merge requests, probably. If somebody does not like a project code, or they do not want to learn the old code, they would not even provide patches or a merge requests, since that would require learning the existing code.
Considering what the first part of em>How to become project owner, maintainer, or co-maintainer says, the rest of the page should assume that the person who offers to be maintainer/co-maintainer is active in the project queue and provided patches / merge requests.

If you are a developer who have been working in the issue queues of a Drupal-contributed project, and you find that your work is being ignored by the maintainers/co-maintainers, the patches you've carefully reviewed do not get committed, or there is no progress, you may be interested in becoming a co-maintainer/maintainer or the project owner in order to further the development of the project.

I will be working on this one - Atlanta Drupal 25

As I don't have permission to edit the page, here is my suggestion to improve the page:

Things You Do Not Have to Worry About

If you are thinking about taking over a project, you might have some doubts in due course. Here are some common concerns and how you can better deal with them:

I don’t like the current code and don’t want to learn it.
- That’s okay. You don’t necessarily have to keep the current code. You can start a new branch and only work on your own version. But the users should be advised since the beginning on the ways of working and would also important to have more context on the why you are starting a new code and the improvements and gains to be obtained with the changes you are doing.

I don’t want to help the old users.
- It is not mandatory that you assist old users. Although it will be a good practice and users will be very appreciated for the help provided. One suggestion is that you can leave a note on the top of the page explaining which is the latest version you support on the project page, so users will have awareness on what kind of assistance they will have.

I don’t want people to think I’m part of a failed project.
- You can change the project page to show what is new and better in your version. This can help people see your work as something useful and clear for everyone.

A Note About Ethics and Trust

Taking over a project should be done in an open and honest way. The community expects people to act with good intentions and having empathy for users. Respect and good intentions are expected so the community can be guided in the best way as possible.

It is also important to note that is you want to adopt a project, make sure your actions are transparent and visible to others. In case you are a co-maintainer you should be aligned with the major maintainer to guarantee you are on the same page. And in the roles of Project Owner and Maintainer would be interesting to follow the good practices the community give.