Dear coreboot folks,
Am 19.02.24 um 22:24 schrieb mina--- via coreboot:
[…]
### [Nico] Revoking Gerrit privileges as punishment. I would like to discuss two matters about this. Not sure about the order.
- My own case: I was removed from the core developers and reviewers groups 20 months ago. Without
any charge nor chance to defend myself. There was Stefan's sentence, a discrediting rant about me with accusations that fit me not more than many other people, and an offer to reduce the sentence to a month if I were willing to come to the table. Which didn't make sense because I reached out to people long before Stefan's mail and it took Stefan, not me, over three months "to come to the table". And then he still couldn't tell me what I did worse than others. I asked again, Werner this time, what my charge is in 2023, again without results. And now I'm asking again. How can we make things better when we can't even say what was wrong? * [Martin] These issues are not discussed in a public forum where everyone with a pitchfork can get involved. That’s not useful. If you feel that the issues which led to this action being taken have changed, please email all the members of the leadership. Matt, Werner, and David.
- Should we use Gerrit privileges as punishment at all? If so, shouldn't we have rules about it?
- We will add this to the code of conduct page:
As a part of running the project, coreboot leadership has the right to revoke privileges as they see fit. This is not done lightly. Over the history of the coreboot project, there have been only a handful of times where an action needed to be taken. Discussions about these actions are not done publicly, for obvious reasons. If someone believes that the circumstances that led to an action have changed, please send an email to all the members of the leadership team for discussion.
- I will note that this text is already there:
If a community member engages in unacceptable behavior, the community organizers may take any action they deem appropriate, up to and including a temporary ban or permanent expulsion from the community without warning (and without refund in the case of a paid event).
In my opinion, some things are missing.
1. First, before “punishing” someone the person needs to be informed and also have the chance to be heard. 2. If the person wants to discuss this publicly, that should be allowed. 3. The length of the “punishment” must be limited.
* Doesn't it hurt the project more when it loses a reviewer? (who can still get their own patches merged anyway). * [Martin] I’d say yes, and that’s something that the leadership group has to weigh when they decide to take an action against an individual. * [David] Yes, it does hurt the project when it loses a reviewer (or any contributor, for that matter). That's why it's important to deal with "toxic developers" effectively - to prevent othersfrom leaving the project. No one developer is worth several others who will refuse to work with them. * Should we maybe do the opposite? don't merge their patches unless they do review? * [Martin] When the issue is something other than the quality of a person’s code, it doesn’t make sense to punish them by refusing to allow their patches to be merged. As many people in the community have jobs where they’re required to push code to coreboot, that could be the equivalent to getting them fired, which seems unfair.
- If we want to use such punishment, should we apply it to other privileges as well? e.g.
administrators, leadership members (IMO very important for trust inside the community) * [Martin] If two members of the leadership voted to take action against a third member, that’s completely allowed. The leadership team can take action as needed. I’ll note that I myself had submit rights taken away for a year. Yes, I’m one of the handful of cases mentioned.
I would keep the status quo. It’s my impression, that until know, these means were enough.
[…]
Kind regards,
Paul
[1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...).