New subject: Code of conduct: Punishment and revoking privileges (was: coreboot Meetings Announcement And Agenda Call, 21.02.24)

19 Feb 2024


      Dear community,
Please note that the upcoming coreboot leadership meeting is scheduled for next Wednesday, February 21, 2024.[1]
You are welcome to update the current agenda items with matters you wish to see addressed during the meeting.[2]
## Current Agenda Items
###  We’ve switched to BigBlueButton for this meeting.
  * https://bbb.sfconservancy.org/b/mar-sfn-e22-axi
  * For phone access, call +1-718-247-9666, then enter 89421 as the conference PIN number. 
    * It looks like there’s only a USA phone number. 
    * I found some apps, but they seem to be to run the meeting, not to join it.
    * See the coreboot calendar for times and more information
### [FelixH] Look at the type that we should be using for readXX
  * Currently we’ve been using void*, but it’s been argued that using an uintptr_t would be preferable.
    * Should we use ‘_Generic’?
  * We’d like to have just a single type.
### [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).
```
  * https://doc.coreboot.org/community/code_of_conduct.html
    * 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 others
from 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.
### [Martin] Remove ChromeEC as a submodule - reimplement like a payload
  * The ChromeEC can currently be built (for some platforms) as a part of the coreboot build. It’s
being downloaded as a submodule right now, but this creates a number of issues. With the change to
Zephyr, the build process and requirements have changed.
   To address this, I’d like to propose that we drop the ChromeEC as a submodule, which restricts us
to a single version of the code which can be used across all mainboards. With an implementation
similar to what’s done for the payloads, the ChromeEC can still be pulled down by platforms which
want to build it, and each platform can select a different commit if needed.
### [Martin] Drop Tioga-pass & Xeon-sp?
  * Marc gave these both +2, so I’m inclined to believe they should be removed, as he was one of the significant contributors, but I’d like to get everyone’s input.
  “The platform code depends on unreleased binary files and uses incomplete public header files.”
  https://review.coreboot.org/c/coreboot/+/80171
  https://review.coreboot.org/c/coreboot/+/80172
  Should they be removed immediately as incomplete and unlikely to be finished?
### 24.02 release
  * The release tag was done on Monday the 19th.
  * The announcement will be done on Monday 2024_02_26.
  * Next release is 24.05.
[1](https://coreboot.org/calendar.html).
[2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...).