Shortening time period after which a person is removed/added to CODEOWNERS

[klaudiagrz]

Context

The current guidelines state that If a maintainer is unresponsive for at least 3 months, he/she can be removed from the maintainers list immediately. Moreover, according to the same guidelines, new codeowners can be added to the list after 3 months of working on the project.

From the Process for becoming a codeowner section:

Because of that, the CODEOWNERS file does not really reflect the reality: it contains names of people no longer working on the project, and people actually working on it do not have codeowners rights. This disrupts the transparency and makes it more difficult to get reviews.

Proposal

To make the codeowners list more transparent, I'd suggest:

1. Shortening the time of unresponsiveness after which a person is removed from CODEOWNERS from 3 months to 1 month, and/or
2. Shortening the time after which a person is added to CODEOWNERS from 3 months to 1 month as well.
3. Shortening the time period after which a person can be removed from codeowners, but keeping 3 months of probatory period for new joiners.
4. Leave the decision on whether someone should become (or stop being) a codeowner to sole discretion of existing code owners and the person interested in becoming one (as this person should not only be appointed but also willing and feeling comfortable).

Decision

Consequences

[Disper]

I’m not sure about whether a good time period exists that will be good for all possible contexts. There might be cases where e.g. 1 month will not be enough for someone to feel comfortable as code owner, while I can image areas where someone can feel comfortable even after one week.

Tiny additional-proposal
Four: Leave decision on whether someone should become (or stop being) a codeowner to sole discretion of existing code owners and the person interested on becoming one (as this person should not only be appointed but also willing and feeling comfortable).

[pbochynski]

You are right - the reality is different. We just add new team members to the codeowner files when they are ready. The guide was prepared mostly for external contributors (outside of kyma-project organization). Please check this proposal. We can simplify the process for our full-time contributors using area teams. Such a solution clearly goes into the 4th option. As for now, we don't have any external code-owners (except those who left our team and became emeritus) but I don't see any problem to use option 4 also for them. Option 4 seems to be shorter, simpler, better :)

[klaudiagrz]

Thank you all for your contribution to the discussion 🙇 I implemented changes to the guidelines as suggested.