Define policy around acceptable contribution guidelines

[codeboten]

As a result of an increase in contributors submitting pull requests, ignoring feedback on them, and then opening new pull requests with similar issues, and again ignoring feedback on those, we've identified that a policy should be defined for how to manage interaction with those contributors.

The suggestion from a previous conversation was that the initial response would be to provide a canned message identifying the 1st offense, and that following offenses may result in the contributor being blocked.

[dyladan]

Ideally this would be applied through automation or GC in order to prevent blowback on individual maintainers with an appeal process. It would also make it easier to apply the policy consistently across repos

[mx-psi]

My suggestion would be that we have something like the following three steps, where the first step is owned by the SIG approvers and maintainers, while the second and third steps are owned by the Governance Committee:

1. On a first rule violation, an approver or maintainer raises a public warning on a Github comment with a clear explanation of the rule being violated, something like:

@[contributor's Github]

I am closing this PR/issue since it goes against [description of rule being violated].

Please review the policies carefully and avoid breaking the rules in the future.

2. For the second rule violation, the Governance Committee liaison would reach out in private over Slack or email if possible with something like this that mentions explicitly that a ban may result from further rules violations:

Hello [contributor's name],

I am [sender's name], one of the [role within the project]. 

I am reaching out to you regarding your recent PRs on [list of repositories], notably [list of examples].

As raised on Github to you, it seems like you have [description of rules that have been violated].

I wanted to reach out over [medium] to make sure that you understand that:
[list of policies with links]

Please note that if you continue disregarding these rules you may be temporarily or permanently banned from the OpenTelemetry Github repositories.

If you have any questions please let me know.

Thank you,
[sender's name]

Reaching out in private is preferred is possible but may not be possible in all cases, in which cases reaching out over Github is justified. I personally would also be okay with a short-term ban here (3 days?)

3. A third rule violation would warrant a ban from the OpenTelemetry Github organization. The Governance Committee would ultimately own this process.

[svrnm]

While reaching out in private is kind towards that person that might not do this with bad intention, it adds unnecessary overhead of finding their email or slack handle, and also puts the person reaching out into a 1:1-situation with them, which can depending on the personalities involved not end in a better situation.

I also argue for an as long as possible, but not permanent ban, giving an additional level of escalation.

I propose the following:

• Send a warning on behalf of the maintainers, close issue/PR
• Send a second warning on behalf of the maintainers, close issue/PR
• Ban for 30 days from org + statement on issue/PR from GC liaison on behalf of the otel project + closing it.
• Repeated offenders get a perma ban from GC, without any further warning, they can send an email to the GC to appeal.

Here's my argument for this harsh policy:

• It's a one way street, maintainers should not have to debate with people if this is justified or not. If someone feels treated unfairly by the maintainer or group of maintainers, they have multiple opportunities to come to the slack channel or SIG call and engage in a conversation. But it's the offender's debt to bring, not the maintainer. If there is really an issue on maintainer site, there is a tool for that already: coc complaint.
• I rather see maintainer spend their time to send emails and slack messages to encourage good citizens of our project, rather spending time with sending them to offenders and have back and forth conversations on why this is justified or not.
• Maintainer's time is right now our biggest bottleneck, and with all the AI slop it becomes worse, this is an uneven battle, so I want us to spare our time and energy.

[mx-psi]

While reaching out in private is kind towards that person that might not do this with bad intention, it adds unnecessary overhead of finding their email or slack handle, and also puts the person reaching out into a 1:1-situation with them, which can depending on the personalities involved not end in a better situation.

I am fine with not requiring but rather just suggesting to reach out in private. I don't think there needs to be a conversation, just a record that the message was sent.

It's a one way street, maintainers should not have to debate with people if this is justified or not. If someone feels treated unfairly by the maintainer or group of maintainers, they have multiple opportunities to come to the slack channel or SIG call and engage in a conversation.

Agreed that we shouldn't make this a debate; the intent is to make it clear for the offender what the consequences are: a ban means more bureacracy (maintainer needs to reach out to admins and/or possibly GC if the GC needs to evaluate the situation), while a formal warning can be done without that internal back-and-forth. Is there a way to expedite the process for maintainers to request temporary bans?

[trask]

I agree with not reaching out 1:1 in these cases, unless a maintainer really wants to (in which case there's nothing preventing them from doing this), but I don't think we need to encode that in the policy.

Is there a way to expedite the process for maintainers to request temporary bans?

Ping any of the @open-telemetry/admins on Slack.

[mx-psi]

Slightly adjacent PR: #3283. I am going to keep as draft until I get some feedback from GC members and then mark as ready for review.

I am also working on more clear instructions on how to enforce this, I will discuss this with the GC before filing a PR for that