Re: Questions around Justice and Our Current CoC procedures

[Russ Allbery]

Scott Kitterman  writes:

> I think that makes sense, but I think it's really pretty much the same
> thing.  The "perceived authority" that means people treat feedback from
> DAM differently is the authority to suspend or expell.  Ultimately and
> unavoidably, a DAM warning comes with an undercurrent of that authority.

I agree with this to an extent, but it sounded in your previous message
like you felt that threat was quite strong, and therefore wanted a slow
and careful process before even warning someone.  This is the part that
worries me.  I'm worried that being too slow about warnings creates
exactly the problems that the project is trying to avoid.  If everything
is formal and slow, that means we end up with much-delayed, very strong
actions on situations that have had time to fester and escalate, which
increases the chances of highly divisive membership decisions.

I want a faster and more responsive process to give people effective
warnings *before* things escalate and fester in the hope that this will
mean fewer escalations to having to take membership actions.

Yes, the fact that the DAM is also responsible for expelling developers
when necessary is the reason why they can't be ignored and therefore the
reason why in some cases the warning is effective, but it's still possible
for a warning to only be a warning.  Specifically, I want a warning that
does *not* imply the sort of "three strikes and you're out" escalation
path that you referred to in your message and which is indeed common in US
employment situations.  I do think there's a place in the project for a
warning from some sort of trusted authority that is not perceived as a
deferred expulsion, but is something that still clearly should not be
ignored.

Or, let me put this another way: one of the fears that I've seen expressed
around warnings is that it's a permanent record sort of thing, or it
starts a file on someone, or otherwise creates a presumption of future bad
behavior.  I think this comes directly from the sort of HR warning in an
employment situation that you mention.  This bothers me a lot.  I think
this perception is very harmful to the project because it creates
excessive shame and anger and fear, which can be quite counterproductive
in attempting to just get someone to shift their behavior.

The ideal outcome in my mind for a warning is that the person warned
doesn't do that thing again, and then *everyone forgets it ever happened*,
at least in any formal sense.  In other words, I want to extend grace and
forgiveness to people, something that HR processes very much do NOT do.
To do that, we need a warning that's just a warning, where nothing further
will be said about it if the warning is received and understood.

BTW, also on that front, I think that announcing DAM warnings to the
project is a serious mistake.  I understand the thought process that went
into that decision, but I really don't agree with it.  The effect is to
make someone feel attacked and shamed publicly, which directly interferes
with the goal of a warning.  It's also one of the major factors in making
people feel like warnings are some sort of permanent black mark against
them, which I strongly do not want to be the case.

To be clear, it's possible what I'm asking for is something less than a
warning and to reserve warnings for essentially formal reprimand or
censure.  In other words, maybe the current DAM warning concept is worth
keeping in some form, and we just need some new thing.

> Ultimately Debian would be a better place if we were more open to
> listening to each other.

I completely agree.

-- 
Russ Allbery (r...@debian.org)  

Re: Questions around Justice and Our Current CoC procedures

[Scott Kitterman]

On February 21, 2022 5:32:35 AM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>> On Sunday, February 20, 2022 10:13:03 PM EST Russ Allbery wrote:
>
>>> I guess the other possibility is that people really want warnings to be
>>> way more serious than any meaning I personally would ascribe to the
>>> word "warning" and are thinking of them as formal project censure or
>>> something akin to that.  In that case, my argument is that we need a
>>> warning that's actually just a warning, and the thing we've got is much
>>> too strong and the real problem is that we don't have something lighter
>>> touch.
>
>> Currently a DAM warning is a suspension/expulsion with deferred
>> execution.
>
>We have wildly different understandings of what a DAM warning is.  Which
>clearly points to a problem that needs to be solved!
>
>> I think every non-government job I've had had a discipline process that
>> went:
>
>> 1.  Verbal warning.
>> 2.  Written warning.
>> 3.  You're fired.
>
>> No, Debian isn't an employer, but I think the sense that DAM warnings
>> are used is similar.
>
>That seems like a mistake to me.  Anything that makes Debian seem more
>like an employer seems like a mistake to me.  We just aren't; we're a
>voluntary association that doesn't have any of the same requirements and
>does not have the employees or facilities to have the same type of formal
>process.  We should actively avoid creating spurious parallels to
>employment processes that we are not following, going to follow, or are
>capable of following.
>
>> I agree with the idea that more feedback with a lighter touch would be a
>> good idea, but I think anything with a lighter touch doesn't need DAM to
>> do it.  We are all empowered to provide other developers feedback when
>> we see concerning behavior.  People just need to do it.  It doesn't take
>> any new rules.
>
>We do need DAM to do it sometimes because sometimes people refuse to
>change their behavior unless someone with perceived authority tells them
>they need to.  Otherwise, they just counter-attack and escalate with the
>person who tried to give them feedback.
>
>I'm not calling out anyone specific here.  I truly don't have anyone
>specific in mind.  This is just standard human stuff; in any sufficiently
>large group of people, and Debian is more than large enough, there are
>going to be a few people like that.  It would be nice if peer feedback
>were always sufficient, but this isn't how humans work.
>
>Given that, and given that we clearly don't want to boot everyone who does
>that (even apart from the fact that the project is loathe to boot anyone
>for almost any reason, sometimes people really do change behavior once
>someone they can't just ignore points out the rules of the community),
>some sort of ability for someone with perceived authority to give a
>warning that's actually just a warning, not an "expulsion with deferred
>execution," is useful.


I think that makes sense, but I think it's really pretty much the same thing.  
The "perceived authority" that means people treat feedback from DAM differently 
is the authority to suspend or expell.  Ultimately and unavoidably, a DAM 
warning comes with an undercurrent of that authority.

If you want a warning without the threat, then don't have it come from DAM.  
This is not an easy problem to solve.  Unfortunately I don't think there's a 
group in the project that is broadly credible enough to take it on based on 
moral authority alone.

Ultimately Debian would be a better place if we were more open to listening to 
each other.

Scott K

Re: Questions around Justice and Our Current CoC procedures

[Russ Allbery]

Scott Kitterman  writes:
> On Sunday, February 20, 2022 10:13:03 PM EST Russ Allbery wrote:

>> I guess the other possibility is that people really want warnings to be
>> way more serious than any meaning I personally would ascribe to the
>> word "warning" and are thinking of them as formal project censure or
>> something akin to that.  In that case, my argument is that we need a
>> warning that's actually just a warning, and the thing we've got is much
>> too strong and the real problem is that we don't have something lighter
>> touch.

> Currently a DAM warning is a suspension/expulsion with deferred
> execution.

We have wildly different understandings of what a DAM warning is.  Which
clearly points to a problem that needs to be solved!

> I think every non-government job I've had had a discipline process that
> went:

> 1.  Verbal warning.
> 2.  Written warning.
> 3.  You're fired.

> No, Debian isn't an employer, but I think the sense that DAM warnings
> are used is similar.

That seems like a mistake to me.  Anything that makes Debian seem more
like an employer seems like a mistake to me.  We just aren't; we're a
voluntary association that doesn't have any of the same requirements and
does not have the employees or facilities to have the same type of formal
process.  We should actively avoid creating spurious parallels to
employment processes that we are not following, going to follow, or are
capable of following.

> I agree with the idea that more feedback with a lighter touch would be a
> good idea, but I think anything with a lighter touch doesn't need DAM to
> do it.  We are all empowered to provide other developers feedback when
> we see concerning behavior.  People just need to do it.  It doesn't take
> any new rules.

We do need DAM to do it sometimes because sometimes people refuse to
change their behavior unless someone with perceived authority tells them
they need to.  Otherwise, they just counter-attack and escalate with the
person who tried to give them feedback.

I'm not calling out anyone specific here.  I truly don't have anyone
specific in mind.  This is just standard human stuff; in any sufficiently
large group of people, and Debian is more than large enough, there are
going to be a few people like that.  It would be nice if peer feedback
were always sufficient, but this isn't how humans work.

Given that, and given that we clearly don't want to boot everyone who does
that (even apart from the fact that the project is loathe to boot anyone
for almost any reason, sometimes people really do change behavior once
someone they can't just ignore points out the rules of the community),
some sort of ability for someone with perceived authority to give a
warning that's actually just a warning, not an "expulsion with deferred
execution," is useful.

-- 
Russ Allbery (r...@debian.org)  

Re: Questions around Justice and Our Current CoC procedures

[Scott Kitterman]

On Sunday, February 20, 2022 10:13:03 PM EST Russ Allbery wrote:
> Sam Hartman  writes:
> > Figuring out how to accomplish requesting a statement is a little
> > tricky, but I think it is worth the effort.  DAM takes membership
> > actions (including warnings) by consensus.  It's fairly difficult to get
> > all the members of DAM together.
> > 
> > I don't think it would work in practice for the request for a statement
> > to be a consensus action and to be followed shortly there after by
> > another consensus action to take a decision and to write it up.  That
> > would require DAM to get together as a group twice in short succession;
> > given how hard it is to schedule DAM action, that would not work.
> 
> I think Debian is in danger of a degenerative spiral, both here and in
> other places.  We make fewer and fewer decisions, slower and slower, which
> raises the cost of reversing a bad decision because it requires a second
> decision, which will also be slow.  This raises the stakes of each
> decision, so they have to be made more carefully.  This makes the decision
> take more effort, and thus we make even fewer decisions, and those
> decisions then carry even more weight.  That in turn leads people to want
> them to be made even more carefully, and the spiral continues until we
> talk endlessly and make no decisions at all.
> 
> We need a careful and slow process for kicking someone out of the project
> because that's a big deal.  Having a careful and slow process for issuing
> a warning is faintly absurd, and I think we've only arrived at that state
> because it's so hard to decide to ever do anything that they've reached an
> unrealistic level of apparent importance.
> 
> I think the solution in many, many places across Debian is to make more
> decisions, faster, and allow some of them to be wrong.  Lower the stakes
> and consequences of a bad decision, and lower the perceived weight of a
> single decision, rather than trying to make every decision perfect.
> 
> Anyway, to be more concrete, what your description of the process says to
> me is that ideally DAM would be much larger and would deal with more minor
> things, such as warnings, in panels.  Have a rotating "on call" or
> something similar, empower them to make decisions on anything that comes
> up while they're on call, and if someone thinks their decision is
> profoundly unfair (I still think people are making far too much out of
> warnings), or if some more serious issue comes up, it can be reviewed by a
> different panel, a larger panel, or by DAM as a whole, but that would be
> rarer.
> 
> Having more people empowered to make decisions faster would also lower the
> perceived significance of each decision, since there's going to be some
> minor human inconsistency and I think that's actually healthy.  The goal
> of warnings is not to precisely measure and describe exactly what someone
> did wrong to some nonexistent objective standard.  It's to say "hey, this
> is making things shitty for other people, you need to knock it off."
> People can grumble about that all they want; the grumbling doesn't require
> a response.  If they think twice about doing the thing that was making
> things shitty for other people, mission accomplished.  If it turns out
> that what they were doing was fine in context, great!  It was a warning;
> no one did anything.  If that was the first warning someone got for
> something they didn't actually do, they've led a way more sheltered life
> than I have, and my life has been pretty sheltered.
> 
> I dunno, I realize I may be being too cavalier here, but see the point
> above about making more decisions, faster, and accepting a few mistakes.
> If we end up with a rash of bogus warnings, we can reconsider.  But right
> now warnings are about as frequent as Papal encyclicals, and I think
> partly as a result people have gotten really weird ideas about them.
> 
> I guess the other possibility is that people really want warnings to be
> way more serious than any meaning I personally would ascribe to the word
> "warning" and are thinking of them as formal project censure or something
> akin to that.  In that case, my argument is that we need a warning that's
> actually just a warning, and the thing we've got is much too strong and
> the real problem is that we don't have something lighter touch.

Currently a DAM warning is a suspension/expulsion with deferred execution.  I 
think every non-government job I've had had a discipline process that went:

1.  Verbal warning.
2.  Written warning.
3.  You're fired.

No, Debian isn't an employer, but I think the sense that DAM warnings are used 
is similar.  I agree with the idea that more feedback with a lighter touch 
would be a good idea, but I think anything with a lighter touch doesn't need 
DAM to do it.  We are all empowered to provide other developers feedback when 
we see concerning behavior.  People just need to do it.  It doesn't take any 
new rules.

Scott K

Re: Questions around Justice and Our Current CoC procedures

[Scott Kitterman]

On Sunday, February 20, 2022 5:24:47 PM EST Sam Hartman wrote:
> > "Felix" == Felix Lechner  writes:
> In the interest of full disclosure, I no longer have any affiliation
> with DAM.
> 
> Felix> With regard to disciplinary proceedings, however, Debian has
> Felix> a long way to go in implementing basic precepts of
> Felix> justice. For example, it would be good to hold hearings in
> Felix> which the accused can make a statement before any action is
> Felix> taken.
> 
> I think phrasing this in terms of justice and rights for keeping
>  governments  accountable  is likely to get a knee-jerk reaction from a
>  number of people who do not want to think of things that.
> It's fairly clear to a number of us that maintaining standards of a
> private community is a very different problem than maintaining justice
> for people who have the power to deny life and liberty.
> 
> I do think there are standards of fairness and desirable conduct in
> managing a community, but I don't think going back to the Magna Carta or
> other documents of human rights is very productive in moving the
> discussion forward.
> 
> However, I do find there are areas where I agree with you.
> I'm going to focus on DAM in this message rather than listmaster or the
> community team.
> I think the calculus for each group works out differently.
> As an example, because the community team cannot (for the most part)
> take formal action, I think it is desirable to avoid too much process
> for them.
> 
> 
> Having witnessed things from a number of angles, I agree with you if
> that I think it would be an improvement if DAM agreed to ask
> a member for input before taking decisions that affect them.
> 
> DAM has long held that they don't do so as a matter of policy.
> I don't have an explicit citation for this, but I'm fairly sure it was
> discussed back in 2019.
> As I understand it, the argument is roughly that by the time things get
> to DAM, they are unambiguous.
> 
> Unfortunately, it really rubs people the wrong way.
> While I think it would be rare that it would change things, membership
> actions are infrequent, and it actually is possible for there to be
> understandings even late in a process that has gotten to DAM.
> And while in theory DAM could change their decision if it became clear
> their was a misunderstood, I think in practice the bar for changing a
> decision after it is made will end up being higher than the bar for
> making a different decision in the first place.
> 
> 
> Figuring out how to accomplish requesting a statement is a little
> tricky, but I think it is worth the effort.  DAM takes membership
> actions (including warnings) by consensus.  It's fairly difficult to get
> all the members of DAM together.
> 
> I don't think it would work in practice for the request for a statement
> to be a consensus action and to be followed shortly there after by
> another consensus action to take a decision and to write it up.  That
> would require DAM to get together as a group twice in short succession;
> given how hard it is to schedule DAM action, that would not work.
> 
> 
> So, for this to be practical, the request for a statement would need to
> be something that a single person, acting on their own (or with some
> input but not full consensus) could do.
> 
> As a result, it's not reasonable to expect DAM to communicate all the
> factors of the case to someone, or even to communicate all the
> potentially public evidence.  It could include a description of the
> triggering event in most cases.
> 
> 
> A message might look something like:
> 
> Hi Sam,
> We are writing to you because we're concerned about your message to blah
> with message-id blah-blah in which you said a bunch of bad things. We're
> considering this is the context of your broader interactions with the
> project and wanted   to give you an
> opportunity to give us any input either about that message or your
> interactions with the project before we decide if we are going to take
> any action.
> We anticipate being able to consider any input in the next 72 hours.
> 
> I honestly think it is achievable for DAM to send messages like that in
> most situations and I think it would improve the perception of fairness.
> 
> There are some cases where there's not a triggering event or where the
> trigger that caused DAM to become focused is not something that can be
> shared.  In those cases, the request for a statement would be a lot more
> vague.
> 
> I appreciate that several in the project would desire that DAM put
> together the level of detail that they would send to the NMC as part of
> handling an appeal and send that to the person whose membership was being
> considered.
> Realistically, that's not achievable given the level of effort involved.
> That's especially true for warnings.
> 
> Felix> Disciplinary actions are sufficiently rare to make that a
> Felix> small burden on the members. Without a jury 

Re: Questions around Justice and Our Current CoC procedures

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

Russ> Sam Hartman  writes:
Russ> I dunno, I realize I may be being too cavalier here, but see
Russ> the point above about making more decisions, faster, and
Russ> accepting a few mistakes.  If we end up with a rash of bogus
Russ> warnings, we can reconsider.  But right now warnings are about
Russ> as frequent as Papal encyclicals, and I think partly as a
Russ> result people have gotten really weird ideas about them.

I mostly agree with you.
And my comments were more directed at more serious membership actions
than warnings.
Although I think most of the time it'd be a good idea to check in with
someone and ask for their side before issuing a warning too.

I note that CT can issue warnings with a lot less process than DAM can.

Russ> I guess the other possibility is that people really want
Russ> warnings to be way more serious than any meaning I personally
Russ> would ascribe to the word "warning" and are thinking of them
Russ> as formal project censure or something akin to that.  In that
Russ> case, my argument is that we need a warning that's actually
Russ> just a warning, and the thing we've got is much too strong and
Russ> the real problem is that we don't have something lighter
Russ> touch.

We've got:

1) individual members acting.
I think we don't get enough of this.
I think that we also don't have a culture where it's sufficiently
strongly expected that you at least consider carefully when fellow
project members tell you that you're making things shitty for you.
It's way too acceptable to say "well, nothing in the rules says I
can't."

2) We've got CT warnings.
I don't know what their internal procedure is now, but it seems like
they don't require as much consensus as when I was involved.

3) We've got DAM warnings.
Mostly, these are more serious than CT warnings, although I'm aware of
situations where the stars lined up and it was easier for DAM to act
than the CT even though either would have been okay.

4) We've got suspension-like things.

5) We've got expulsion-like things.

And somewhere between 2 and 4 we've got mailing list bans, bts bans, IRC
operator action an dthe like.

I absolutely agree it would be great if we had more warnings (especially
down at level 1 from individual developers) and we made it easier for
warnings to be given.

I also agree it may well be the case that DAM warnings have too much
formality.

--Sam

Re: Questions around Justice and Our Current CoC procedures

[Russ Allbery]

Sam Hartman  writes:

> Figuring out how to accomplish requesting a statement is a little
> tricky, but I think it is worth the effort.  DAM takes membership
> actions (including warnings) by consensus.  It's fairly difficult to get
> all the members of DAM together.

> I don't think it would work in practice for the request for a statement
> to be a consensus action and to be followed shortly there after by
> another consensus action to take a decision and to write it up.  That
> would require DAM to get together as a group twice in short succession;
> given how hard it is to schedule DAM action, that would not work.

I think Debian is in danger of a degenerative spiral, both here and in
other places.  We make fewer and fewer decisions, slower and slower, which
raises the cost of reversing a bad decision because it requires a second
decision, which will also be slow.  This raises the stakes of each
decision, so they have to be made more carefully.  This makes the decision
take more effort, and thus we make even fewer decisions, and those
decisions then carry even more weight.  That in turn leads people to want
them to be made even more carefully, and the spiral continues until we
talk endlessly and make no decisions at all.

We need a careful and slow process for kicking someone out of the project
because that's a big deal.  Having a careful and slow process for issuing
a warning is faintly absurd, and I think we've only arrived at that state
because it's so hard to decide to ever do anything that they've reached an
unrealistic level of apparent importance.

I think the solution in many, many places across Debian is to make more
decisions, faster, and allow some of them to be wrong.  Lower the stakes
and consequences of a bad decision, and lower the perceived weight of a
single decision, rather than trying to make every decision perfect.

Anyway, to be more concrete, what your description of the process says to
me is that ideally DAM would be much larger and would deal with more minor
things, such as warnings, in panels.  Have a rotating "on call" or
something similar, empower them to make decisions on anything that comes
up while they're on call, and if someone thinks their decision is
profoundly unfair (I still think people are making far too much out of
warnings), or if some more serious issue comes up, it can be reviewed by a
different panel, a larger panel, or by DAM as a whole, but that would be
rarer.

Having more people empowered to make decisions faster would also lower the
perceived significance of each decision, since there's going to be some
minor human inconsistency and I think that's actually healthy.  The goal
of warnings is not to precisely measure and describe exactly what someone
did wrong to some nonexistent objective standard.  It's to say "hey, this
is making things shitty for other people, you need to knock it off."
People can grumble about that all they want; the grumbling doesn't require
a response.  If they think twice about doing the thing that was making
things shitty for other people, mission accomplished.  If it turns out
that what they were doing was fine in context, great!  It was a warning;
no one did anything.  If that was the first warning someone got for
something they didn't actually do, they've led a way more sheltered life
than I have, and my life has been pretty sheltered.

I dunno, I realize I may be being too cavalier here, but see the point
above about making more decisions, faster, and accepting a few mistakes.
If we end up with a rash of bogus warnings, we can reconsider.  But right
now warnings are about as frequent as Papal encyclicals, and I think
partly as a result people have gotten really weird ideas about them.

I guess the other possibility is that people really want warnings to be
way more serious than any meaning I personally would ascribe to the word
"warning" and are thinking of them as formal project censure or something
akin to that.  In that case, my argument is that we need a warning that's
actually just a warning, and the thing we've got is much too strong and
the real problem is that we don't have something lighter touch.

-- 
Russ Allbery (r...@debian.org)  

Re: Questions around Justice and Our Current CoC procedures

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

Felix> Alas, I'll venture that the folks whose opinions you consider
Felix> superior have never been punished.

The word punished implies a framing of the problem I personally reject.
But if for example you'd consider being banned from the BTS a
punishment, then your claim is incorrect.


But my opinion doesn't really matter here except in so much as I gain
social credibility by dealing reasonably with people.
Ultimately, the question is how  does the project feel about how the DPL
and delegates are doing things.

I personally think that we need a clear explanation so that the project
can come to an informed opinion and express that opinion through
discussions, through DPL elections, and through GRs.

--Sam

Re: Jan 2022 DPL/DAM/CT sprint report

[Pierre-Elliott Bécue]

Felix Lechner  wrote on 20/02/2022 at 22:22:51+0100:

> Hi,
>
> On Sun, Feb 20, 2022 at 12:55 PM Pierre-Elliott Bécue  wrote:
>>
>> Cc-ing you, but if you prefer not being replied directly for lists on
>> which you're subscribed, please do tell.
>
> Without specific requests to the contrary, I copy folks only on bugs
> and not on lists but please handle that as you see fit. My mail system
> deletes the duplicate automatically.

Ack, I'll try not to Cc you, but I note that it'd not be a big deal.

>> But for warnings, it'd
>> become quite too expensive to hold any sort of trial, especially when
>> the grounds for the warning are public and warrant for a warning
>> independently of what could have caused them.
>
> How can warnings ever be warranted "independently of what could have
> caused them"?

If I insult you publicly, whatever you did privately or publicly, I
still do insult you publicly, and that's against a CoC. It is my opinion
that I still would deserve a warning for that insult.

>> > The burden should be the
>> > other way around, i.e the membership should be forced to affirm a
>> > disciplinary DAM action if the accused does not mind the publicity.
>> > Upon failure, the accused should walk.
>>
>> I'm not sure to understand the meaning of the two last sentences, could
>> you please elaborate on these?
>
> With fewer than two disciplinary actions per year, it is not an undue
> burden on the membership to ratify punishments at the request of the
> accused.
>
> The DAM action should be withdrawn unless the membership affirms it in
> a general vote.
>
> It's better for DAM, too. Since the decision is made by the project as
> a whole, all accusations of bias are automatically moot. The defeat of
> the accused is final. It warrants no further review unless the
> evidence was flawed.

The issue with that is that it can become a huge mud spread quite fast.

(and btw, who does check whether the evidence was flawed?)

-- 
PEB


signature.asc
Description: PGP signature

Re: Questions around Justice and Our Current CoC procedures

[Pierre-Elliott Bécue]

Felix Lechner  wrote on 20/02/2022 at 23:42:31+0100:

> Hi,
>
> On Sun, Feb 20, 2022 at 2:25 PM Sam Hartman  wrote:
>>
>> A number of people over the years have talked about embodying some of
>> the processes and protections of a trial in community management actions
>> in Debian.  That has included ideas like having the project as a whole
>> decide/affirm the decision, making evidence available, giving the
>> "accused" access to evidence and access to those who have made claims
>> against them.
>>
>> I think there's broad agreement among those who have actually worked on
>> community management in Debian that this would be a horrible idea and
>> would not make Debian a welcoming community.
>
> Alas, I'll venture that the folks whose opinions you consider superior
> have never been punished.

I am not convinced that, even if that were right, it'd make the argument
invalid in any way.

-- 
PEB


signature.asc
Description: PGP signature

Re: Questions around Justice and Our Current CoC procedures

[Felix Lechner]

Hi,

On Sun, Feb 20, 2022 at 2:25 PM Sam Hartman  wrote:
>
> A number of people over the years have talked about embodying some of
> the processes and protections of a trial in community management actions
> in Debian.  That has included ideas like having the project as a whole
> decide/affirm the decision, making evidence available, giving the
> "accused" access to evidence and access to those who have made claims
> against them.
>
> I think there's broad agreement among those who have actually worked on
> community management in Debian that this would be a horrible idea and
> would not make Debian a welcoming community.

Alas, I'll venture that the folks whose opinions you consider superior
have never been punished.

Kind regards
Felix Lechner

Questions around Justice and Our Current CoC procedures

[Sam Hartman]

> "Felix" == Felix Lechner  writes:

In the interest of full disclosure, I no longer have any affiliation
with DAM.

Felix> With regard to disciplinary proceedings, however, Debian has
Felix> a long way to go in implementing basic precepts of
Felix> justice. For example, it would be good to hold hearings in
Felix> which the accused can make a statement before any action is
Felix> taken.

I think phrasing this in terms of justice and rights for keeping
 governments  accountable  is likely to get a knee-jerk reaction from a
 number of people who do not want to think of things that.
It's fairly clear to a number of us that maintaining standards of a
private community is a very different problem than maintaining justice
for people who have the power to deny life and liberty.

I do think there are standards of fairness and desirable conduct in
managing a community, but I don't think going back to the Magna Carta or
other documents of human rights is very productive in moving the
discussion forward.

However, I do find there are areas where I agree with you.
I'm going to focus on DAM in this message rather than listmaster or the
community team.
I think the calculus for each group works out differently.
As an example, because the community team cannot (for the most part)
take formal action, I think it is desirable to avoid too much process
for them.


Having witnessed things from a number of angles, I agree with you if
that I think it would be an improvement if DAM agreed to ask
a member for input before taking decisions that affect them.

DAM has long held that they don't do so as a matter of policy.
I don't have an explicit citation for this, but I'm fairly sure it was
discussed back in 2019.
As I understand it, the argument is roughly that by the time things get
to DAM, they are unambiguous.

Unfortunately, it really rubs people the wrong way.
While I think it would be rare that it would change things, membership
actions are infrequent, and it actually is possible for there to be
understandings even late in a process that has gotten to DAM.
And while in theory DAM could change their decision if it became clear
their was a misunderstood, I think in practice the bar for changing a
decision after it is made will end up being higher than the bar for
making a different decision in the first place.


Figuring out how to accomplish requesting a statement is a little
tricky, but I think it is worth the effort.  DAM takes membership
actions (including warnings) by consensus.  It's fairly difficult to get
all the members of DAM together.

I don't think it would work in practice for the request for a statement
to be a consensus action and to be followed shortly there after by
another consensus action to take a decision and to write it up.  That
would require DAM to get together as a group twice in short succession;
given how hard it is to schedule DAM action, that would not work.


So, for this to be practical, the request for a statement would need to
be something that a single person, acting on their own (or with some
input but not full consensus) could do.

As a result, it's not reasonable to expect DAM to communicate all the
factors of the case to someone, or even to communicate all the
potentially public evidence.  It could include a description of the
triggering event in most cases.


A message might look something like:

Hi Sam,
We are writing to you because we're concerned about your message to blah
with message-id blah-blah in which you said a bunch of bad things.
We're considering this is the context of your broader interactions with
the project and wanted   to give you an
opportunity to give us any input either about that message or your
interactions with the project before we decide if we are going to take
any action.
We anticipate being able to consider any input in the next 72 hours.

I honestly think it is achievable for DAM to send messages like that in
most situations and I think it would improve the perception of fairness.

There are some cases where there's not a triggering event or where the
trigger that caused DAM to become focused is not something that can be
shared.  In those cases, the request for a statement would be a lot more
vague.

I appreciate that several in the project would desire that DAM put
together the level of detail that they would send to the NMC as part of
handling an appeal and send that to the person whose membership was being
considered.
Realistically, that's not achievable given the level of effort involved.
That's especially true for warnings.

Felix> Disciplinary actions are sufficiently rare to make that a
Felix> small burden on the members. Without a jury system, it is the
Felix> best we can do to offer a trial by our peers. Thank you!

A number of people over the years have talked about embodying some of
the processes and protections of a trial in community management actions
in Debian.  That has 

Re: Jan 2022 DPL/DAM/CT sprint report

[Felix Lechner]

Hi,

On Sun, Feb 20, 2022 at 12:55 PM Pierre-Elliott Bécue  wrote:
>
> Cc-ing you, but if you prefer not being replied directly for lists on
> which you're subscribed, please do tell.

Without specific requests to the contrary, I copy folks only on bugs
and not on lists but please handle that as you see fit. My mail system
deletes the duplicate automatically.

> But for warnings, it'd
> become quite too expensive to hold any sort of trial, especially when
> the grounds for the warning are public and warrant for a warning
> independently of what could have caused them.

How can warnings ever be warranted "independently of what could have
caused them"?

> > The burden should be the
> > other way around, i.e the membership should be forced to affirm a
> > disciplinary DAM action if the accused does not mind the publicity.
> > Upon failure, the accused should walk.
>
> I'm not sure to understand the meaning of the two last sentences, could
> you please elaborate on these?

With fewer than two disciplinary actions per year, it is not an undue
burden on the membership to ratify punishments at the request of the
accused.

The DAM action should be withdrawn unless the membership affirms it in
a general vote.

It's better for DAM, too. Since the decision is made by the project as
a whole, all accusations of bias are automatically moot. The defeat of
the accused is final. It warrants no further review unless the
evidence was flawed.

Kind regards
Felix Lechner

Re: Jan 2022 DPL/DAM/CT sprint report

[Pierre-Elliott Bécue]

Cc-ing you, but if you prefer not being replied directly for lists on
which you're subscribed, please do tell.

Felix Lechner  wrote on 20/02/2022 at 20:50:24+0100:

> Hi,
>
> On Sun, Feb 20, 2022 at 10:23 AM Steve McIntyre <93...@debian.org> wrote:
>>
>> We should **not** be using the CoC as a hammer, a tool to punish
>> people. It's a set of guidelines, setting basic expectations about
>> interactions one is going to have with people in Debian. People make
>> mistakes - we're only human.
>
> As a recent recipient of a DAM warning—for an isolated incident in
> which I described someone as a "freak" to a third party while that
> person was present—I found Steve's email comforting.
>
> With regard to disciplinary proceedings, however, Debian has a long
> way to go in implementing basic precepts of justice. For example, it
> would be good to hold hearings in which the accused can make a
> statement before any action is taken.

IMHO, yeah, it would be good, and it's the sort of procedure the appeal
made by DAM represents when someone gets removed. But for warnings, it'd
become quite too expensive to hold any sort of trial, especially when
the grounds for the warning are public and warrant for a warning
independently of what could have caused them.

> Those rights go back to the Magna Carta in 1215 and predate any modern
> form of elected government. Instead, they limited the arbitrary and
> capricious nature of unelected officials, namely the Kings of England.
> As someone who has felt the stick (or, as Steve wrote, the "hammer") I
> plead with DPL, DAM, CT to implement such basic protections without
> further delay.
>
> Also, I do not know which avenues of recourse were open to me at the
> time—and did not challenge the warning in any event—but it was unfair
> for some folks to suggest a GR in response. The burden should be the
> other way around, i.e the membership should be forced to affirm a
> disciplinary DAM action if the accused does not mind the publicity.
> Upon failure, the accused should walk.

I'm not sure to understand the meaning of the two last sentences, could
you please elaborate on these?

Cheers,
-- 
PEB


signature.asc
Description: PGP signature

Re: Jan 2022 DPL/DAM/CT sprint report

[Felix Lechner]

Hi,

On Sun, Feb 20, 2022 at 10:23 AM Steve McIntyre <93...@debian.org> wrote:
>
> We should **not** be using the CoC as a hammer, a tool to punish
> people. It's a set of guidelines, setting basic expectations about
> interactions one is going to have with people in Debian. People make
> mistakes - we're only human.

As a recent recipient of a DAM warning—for an isolated incident in
which I described someone as a "freak" to a third party while that
person was present—I found Steve's email comforting.

With regard to disciplinary proceedings, however, Debian has a long
way to go in implementing basic precepts of justice. For example, it
would be good to hold hearings in which the accused can make a
statement before any action is taken.

Those rights go back to the Magna Carta in 1215 and predate any modern
form of elected government. Instead, they limited the arbitrary and
capricious nature of unelected officials, namely the Kings of England.
As someone who has felt the stick (or, as Steve wrote, the "hammer") I
plead with DPL, DAM, CT to implement such basic protections without
further delay.

Also, I do not know which avenues of recourse were open to me at the
time—and did not challenge the warning in any event—but it was unfair
for some folks to suggest a GR in response. The burden should be the
other way around, i.e the membership should be forced to affirm a
disciplinary DAM action if the accused does not mind the publicity.
Upon failure, the accused should walk.

Disciplinary actions are sufficiently rare to make that a small burden
on the members. Without a jury system, it is the best we can do to
offer a trial by our peers. Thank you!

Kind regards
Felix Lechner

Re: Jan 2022 DPL/DAM/CT sprint report

[Steve McIntyre]

And of course I missed one update here... :-(

On Sun, Feb 20, 2022 at 06:20:33PM +, Steve McIntyre wrote:
>
>### Community Team
>
>CT has been delegated with little power to **enforce** anything
>directly [1].

...

>[1] https://lists.debian.org/debian-devel-announce/2020/08/msg0.html

Apologies, this should obviously instead be a link to the most recent
delegation update that happened after I started the sprint write-up:

  https://lists.debian.org/debian-devel-announce/2022/01/msg0.html

-- 
Steve McIntyre  93...@debian.org
Debian Community Team   commun...@debian.org


signature.asc
Description: PGP signature

Jan 2022 DPL/DAM/CT sprint report

[Steve McIntyre]

Hi all!

The DPL, Debian Account Managers (DAM) and Community Team participated
in a sprint on 12th-15th January 2022. We had initially hoped this
could be an in-person event, but in the end that proved impossible and
we chose to hold the event entirely online. All team members were
invited, but time zones and other commitments meant not everybody
could attend all the sessions. The following people were present for
at least some of the sessions:

   * Jonathan Carter - JC (DPL)
   * Enrico Zini - EZ (DAM)
   * Joerg Jaspert - JJ (DAM)
   * Sam Hartman - SH (DAM)
   * Jonathan Wiltshire - JW (DAM)
   * Nicolas Dandrimont - ND (DAM)
   * Steve McIntyre - SM (CT)
   * Andy Cater - AC (CT)
   * Jean-Philippe Mengual - JPM (CT)
   * Molly de Blanc - MdB (CT)

## Summary

Sorry, this is a long document. We covered a lot of ground in four
days! Here's a quick TL;DR.

   * We had a wide-ranging discussion about the roles and
 responsibilities of our teams within Debian, and we have ideas on
 how to improve the setup.
   * We know that our processes and workflows are not as good as they
 should be, we're going to work on that. We're managing OK on most
 issues, but we don't always pick up on everything we should.
   * Recruitment and retention of team members is an ongoing issue,
 and we had a long conversation about what we might do here.
   * Is our CoC fit for purpose?

## (Wed)
## Status updates

Each team presented a summary of current and recent issues. As the
vast majority of the cases include personal data, for the sake of
privacy this report will not give details about them.

## Lessons learned

On a more general note, we also discussed what lessons we have learned
in the teams from the issues we've worked on. These apply in a few
areas.

### Data handling

Processing and keeping track of data about people is difficult, but
sometimes necessary. When keeping records, we should be careful about
what we keep and how.

In cases of abusive behaviour, it helps to construct a timeline of
what's happened - this may be very important later. Therefore, logging
timestamps is useful. Similarly, we should keep a list of people
affected.

### Working effectively in our teams

Importantly (for team members and others!): don't be on your own,
don't feel like nobody's supporting you, ask for help (even multiple
times/regularly, if needed).

Spending project money on the skills of professionals is perfectly
reasonable, and we have money to pay for it. (This was discussed more
in-depth later. Raphaël et al are working on a survey about how people
in the community feel about spending money, which would help direct
these efforts.)  Debian has contracted with lawyers to provide legal
advice in certain situations, and also has a contract with a
PR/anti-harassment organisation. It's fair to make use of people like
this when necessary.

It can be hard work to deal with issues. Time management and **input**
management can be critical so as not to be swamped. Being interrupted
at random times by bad stuff is very draining, and this can be hard to
manage. Some folks have individual tools to help here (e.g. to
temporarily pause email access), and we're going to look into sharing
the ideas we have. Tip: give something a priority and a separate
urgency so something can be **vital** but not **urgent**. Goal: Find
ways to re-distribute or transfer responsibility of handling emergency
situations.

### Working more generally

Generally we do have the support of the project when we do stuff, and
this is important to recognise. We'll often get complaints, but that's
likely to happen in any large group. It helps if we can share obvious
context/reasons for decisions, and not "just" a pattern of
micro-aggressions.

Reaching out to people **early** and asking "are things OK?" can very
often defuse things. It's good to stop small problems growing into big
ones. Equally, calling out apparently bad behaviour early can help. It
doesn't hurt to ask people to explain what they **really** mean if
they're being vague

## Burnout

Wider discussion. Burnout is a perennial problem everywhere in
Debian. Could we find people with experience here to reach out and
help others? The Ubuntu CoC includes "Step down considerately". People
are volunteers, but once you've volunteered it's not cool to just drop
things. We should all encourage people to take breaks. Consider
people's well-being: simple questions like "how are you doing?" cost
little, but can really help. Lots of people end up identifying with
the technical things they do, and that's a hard thing to
change/fix. It can be very difficult to step back and take "me" time,
allowing others to pick things up.

## (Thu)
## Team responsibilities

What do DAM and CT do? We had a discussion about what the teams do,
how they interact and what we might like to change. Obviously, we also
needed to understand the responsibilities and powers of the teams
first before going too deep into the 

Re: Polling informally Debian Contributors

[Serafeim Zanikolas]

On Thu, Feb 17, 2022 at 9:26 AM Andrey Rahmatullin  wrote:
>
> On Thu, Feb 17, 2022 at 10:02:13AM +0100, Philip Hands wrote:
> [..]
> You described Reddit, just with some very complicated integration with
> your mail client.

Apologies for jumping into this, despite not having time to
participate properly in theconversation.

I would urge folks driving this effort to have a look at Audrey Tang's
description of the platform they've been using for country-wide
consensus building in Taiwan.

They have a reddit-like system but _without_ a reply button (nor IIRC
a downvote button). That tiny ux change means that:

- agreeing is effortless (just press upvote button)

- disagreeing requires _constructive_ work (one has to make a new
post, that actually proposes something, rather than merely criticise
somebody else's)

- a controversial post can be ignored, and only if it gathers a
non-trivial number of upvotes one feels the need to do something about
(aka xkcd.com/386)

Their implementation is open-source but I doubt that it'd work for
Debian. We'd need something that integrates with email and gpg
signatures. It could be email in, web out (much like our BTS),
although technically one could also have web in, to accommodate folks
that are more keen on a forum like interface.

Needless to say that this'd take a significant amount of work to
design and develop. Somebody would need to figure out the relation
between email threads and polls (and counter positions in the same
topic).

I don't have time to participate in centi-threads, let alone work on
this, but I'd be happy to review any relevant docs in this direction.