Handling attacks on a community
Handling attacks on a community
Posted Mar 15, 2020 11:15 UTC (Sun) by mvdwege (guest, #113583)Parent article: Handling attacks on a community
At a certain point you just have to say: "Don't like systemd? Move to Devuan"; "Harassing asshole? Get out". That it took until Daniel's meltdown for Sam to finally lose his patience has not helped detoxifying the community.
Posted Mar 16, 2020 11:04 UTC (Mon)
by timrichardson (subscriber, #72836)
[Link] (1 responses)
Posted Mar 17, 2020 15:42 UTC (Tue)
by mvdwege (guest, #113583)
[Link]
Unfortunately, the project has recently had a few very toxic episodes where I think the better solution would be to just expel the members who keep stoking the flames, regarding of past contributions. The way they keep people away is, I think, a bigger loss than the potential contributions of less abrasive replacements.
This of course is not the DPL's responsibility under the constitution, unless it gets so bad it falls under "3. Make any decision which requires urgent action." But Sam did use his power under "9. Lead discussions amongst Developers."[1] to quench toxic threads on the mailing lists, and in my personal opinion too many times waited 2 or 3 mails too long.
[1] I assume that is the article Sam used to declare threads closed, from my reading of the constitution.
Posted Mar 16, 2020 16:39 UTC (Mon)
by hartmans (subscriber, #135969)
[Link] (1 responses)
Posted Mar 17, 2020 15:32 UTC (Tue)
by mvdwege (guest, #113583)
[Link]
That difference in personality also means that sometimes I thought when a discussion was exploding "I wish Sam was a little more decisive". You do eventually come to the conclusion that consensus is impossible, and then you are decisive. I just think that you left it a few iterations of discussion too long on occasion.
And yes, I picked the recent flare-up of systemd as an example, because on debian-devel and debian-project you were focusing more on process issues and less on keeping the Devuan supporters in line, IMO. I could have read that wrong, that's inherent in non-FtF communication. In that case I apologise.
Handling attacks on a community
It would arguably be more disappointing if he wasn't faithful to his manifesto, which is kind of a social contract.
Handling attacks on a community
When Consensus is Appropriate
Consensus was not possible there, and it was obvious to me by the time I was elected that was true.
Similarly, I have never tried to engage with Daniel Pocock in a consensus discussion while I was DPL.
Why didn't I fully ban Daniel from the project earlier? Honestly, by the time I became DPL, I thought that had effectively been done.
I didn't consider that he'd use the bug tracking system in that way until he did.
Why didn't we make a public statement about Daniel earlier?
For a while, we weren't sure it was necessary. Especially during the first part of my term, I was deferring to others.
Later, though, we weren't quite sure how to do it. But then the time for immediate action was at hand and I made that statement because it was necessary.
In no point was this about building a consensus with Daniel.
Some parts of Debian's response did involve waiting for consensus to emerge within teams responsible for handling harassment. And some decisions aren't entirely the DPL's to make and so I waited on others to come to their decisions.
Consensus is a valuable tool, but I assure you it is not always the right answer.
When Consensus is Appropriate