docs introduce `.github/CODEOWNERS` for eclipse-tractusx/eclipse-tractusx.github.io

[FaGru3n]

As this PR is not introduceing branch protection and required review count to the GH Org but to the eclipse-tractusx/eclipse-tractusx.github.io repo only, I would like to require 2 reviewers. For this repository enough stakeholders should be available doing reviews.

Maybe we should also think about to introcude .github/CODEOWNERS (for eclipse-tractusx/eclipse-tractusx.github.io). Code owners are automatically assigned to new PRs: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

_Originally posted by @carslen in https://github.com/eclipse-tractusx/.eclipsefdn/pull/43#discussion_r1410429486_

[SebastianBezold]

IMHO, CODEOWNERS won't add a lot of value or improvement to our current collaboration workflow. Currently it is as follows:

• Everyone can open a PR (contribute)
• Before being able to merge, TWO approvals from reviewers are required
• The approvals have to be given by people with the committer role
• Only committers can merge an approved PR

Potential things a CODEOWNERS file could be used for:

• Path specific permissions (i.e. /docs/release or KITs)
• Auto-Assign reviewers on new PRs

Things that we are limited in my opinion:

• We do only have a committer group, so assigning permissions on group level might be difficult (individual assignments would be needed i guess)

[mhellmeier]

I would vote for a CODEOWNERS file. Especially for the KITs, there are some specific persons and responsibilities.

If someone creates a PR or an Issue for your KIT, you as a KIT developer don't get information that someone wants to change your KIT. You could subscribe to the repository, but in this case, you get notifications for every PR and Issue. Thus, a CODEOWNERS file would be beneficial.

[SebastianBezold]

Hi @mhellmeier, while I can see your points, I think, that this rather indicates a missing contribution guideline. Why would there even be surprise PRs? Why would a contributor doing that not actively ask for feedback on the mailing list or the Matrix chat. So I think, CODEOWNERS do mitigate that issue, but from my point of view, on the wrong end of the process. But again, fair points, that you bring up. Would love to see more opinions on that

[mhellmeier]

Why would a contributor doing that not actively ask for feedback on the mailing list or the Matrix chat.

If it is an external contributor, they may not know that there is a mailing list or Matrix chat. If it were used very actively, it could be spammy since one mail could be sent for every PR.

Take a look at the recent Markdown linter issues for the KITs: If there were a CODEOWNERS file, this would improve the process drastically. Therefore, I don't see any big disadvantages in introducing a CODEOWNERS file.

I would also like to mention one of the latest GitHub blog posts, discussing such a CODEOWNERS file and ways to keep it up-to-date automatically: https://github.blog/2024-03-04-keeping-repository-maintainer-information-accurate/

Happy to hear your opinion on that and how we go on with it!

[arnoweiss]

I think CODEOWNERS could help on the margins but I don't expect any big changes for the challenges we have. Would be open for a PR (and to be responsible for the DT Kit) though.