Re: Q to both candidates: preventing burnout by other contributors

[Mehdi Dogguy]

Hi Russ,

Sorry for the late reply.

On 29/03/2017 18:33, Russ Allbery wrote:
> 1. Do you agree with the above analysis, or do you see a different
>dynamic?
> 

I agree with your analysis. But even in companies, there are issues
and not all managers are able to deal with them. And really, it is
not always because of managers' skills. There are cases really difficult
to deal with, and require some help from qualified persons.

> 2. Do you have any thoughts or plans around how to more proactively
>address social problems that fall short of explusion but that will
>require some teeth and actual consequences to get at least one of the
>parties to be willing to change their behavior?

Some simple solutions like a phone call before a social event to check
the intentions and plans of the person. If we are speaking of cases that
fall short of expulsion, this could help to prevent new issues. A
temporary ban from event or from Debian systems could also be dissuasive
depending on the issue at hand. The idea is to show that misbehavior will
not be left unpunished.

-- 
Mehdi

Re: Q to both candidates: preventing burnout by other contributors

[Antoine Beaupre]

On 2017-03-30 15:39:00, Chris Lamb wrote:
> It seems to be an incredibly difficult skill to master and I cannot claim
> to have substantial prior experience. Perhaps it wasn't Zack-as-DPL that
> helped move those particular conversations along but rather Zack's mediation
> skills…? What do you think?

That's true.. And maybe it's not a skill we should necessarily expect
from a DPL, but I'd love to see that role as some sort of a
mediator. After all, our website does state that:

A main task of the Project Leader therefore involves coordination
and communication.

The constitution also states that:

3. Make any decision which requires urgent action

(although it does say below: "This does not apply to decisions which
have only become gradually urgent through lack of relevant action,
unless there is a fixed deadline." which is arguably the case for
the debconf situation)

and:

9. Lead discussions amongst Developers.

Project Leader should attempt to participate in discussions amongst
the Developers in a helpful way which seeks to bring the discussion
to bear on the key issues at hand.

So I would certainly feel much better if we had a leader with strong
mediation skills.

And i'm not saying you don't have those skills, in fact, I have found
you to be generally quite competent at communicating online so far. :)

A.

-- 
La guerre, c'est le massacre d'hommes qui ne se connaissent pas,
au profit d'hommes qui se connaissent mais ne se massacreront pas.
- Paul Valéry

Re: Q to both candidates: preventing burnout by other contributors

[Chris Lamb]

Hey Antoine,

> One thing I remember seeing Zack do fairly often in his time as a DPL
> was to intervene in certain threads to provide a summary and try to find
> a way out of difficult situations.

I've seen a number of DDs attempt this route. Some succeed but unfortunately
many fail or at least do not effectively clarify the situation, merely adding
yet another voice to the conversation.

It seems to be an incredibly difficult skill to master and I cannot claim
to have substantial prior experience. Perhaps it wasn't Zack-as-DPL that
helped move those particular conversations along but rather Zack's mediation
skills…? What do you think?

> Putting victims in front of their opprossors can put a tremendous
> emotional load on the victim and cause another traumatic event to
> occur

Of course. Meetups would only suitable to "iron out" technical conflicts
that have inflamed or, say, when a developer is behaving poorly in a team
in general and certainly not when there is a direct victim-oppressor
situation. Apologies this wasn't clearer in my previous mail; I was trying
to keep the two cases distinct.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Q to both candidates: preventing burnout by other contributors

[Ian Jackson]

Enrico Zini writes ("Re: Q to both candidates: preventing burnout by other 
contributors"):
> On Wed, Mar 29, 2017 at 07:19:31PM +0100, Chris Lamb wrote:
> > However, I still think that by continually and reliably calling it out
> > in general, even in cases where it is unlikely to worsen, means that
> > our culture will — in time — change for the better.
> 
> I've seen calling out mentioned a number of times. Sometimes I feel like
> the escalation involved in calling out makes sense, and sometimes I
> feel like an escalation would be unnecessary or unwarranted. For those
> times, I am fascinated by the idea of "calling people in":
> 
> https://www.theodysseyonline.com/calling-in-verses-calling-out
> http://everydayfeminism.com/2015/01/guide-to-calling-in/
> https://ofcourseitsaboutyou.com/2014/01/23/calling-out-vs-calling-in-how-activist-techniques-can-be-used-to-decrease-lateral-violence-and-bullying-in-nursing/

Thanks for this.

Ian.

Re: Q to both candidates: preventing burnout by other contributors

[Antoine Beaupre]

Hi Chris,

Thank you for adressing those difficult questions, and thanks for
everyone who stepped up to bring them forward. This is probably one of
the most important discussions right now in the free software world (if
not in STEM overall)...

On 2017-03-29 19:19:31, Chris Lamb wrote:
>> 2. Do you have any thoughts or plans around how to more proactively
>>address social problems that fall short of explusion
>
> If I claimed I had a foolproof solution to this problem I would either
> be a liar or the saviour of the free software movement in general…
>
> (I'm also somewhat hesitant to give my ideas without some kind of caveat
> that its remains unclear to me whether it should be the role of the DPL
> to *rule* or even have any input whatsoever on such cases.)
>
> However, I still think that by continually and reliably calling it out
> in general, even in cases where it is unlikely to worsen, means that
> our culture will — in time — change for the better.
>
> For specific cases, we could look into a "traffic light" warning systems
> but moreover make the process of escalation to some kind of third-party 
> mediator more frictionless.

The thing is: we're not expecting you to solve all the problems, you are
just one person, after all. But as the DPL, you do have a specific, if
sometimes symbolic role. This is something everyone can do but, somehow,
we are socialized to take a step back and consider it more seriously
when it comes from leader@.

One thing I remember seeing Zack do fairly often in his time as a DPL
was to intervene in certain threads to provide a summary and try to find
a way out of difficult situations.

I think this is what good leaders can do: synthesize quiproquos and
conflicts, try to find ways out.

Furthermore, I believe it is everyone's responsability to "call people
in", as Enrico so interestingly put it: don't let crap behavior pass
by. It doesn't have to be in public, and it doesn't have to be against
the perpetrator either: sometimes, receiving positive comments, as a
victim, goes a long way in alleviating the impact of the crap that was
received.

Because, after all, when all is done, it's too late to protect the
victim once the harrassment has happened. All we can do for them is
heal and follow process.

But I also think the DPL could specifically intervene in case of
emergencies, where the harrassment team is too busy or doesn't have time
to respond. I'm not exactly clear on what the process is for contacting
the anti-harassment team, or what's the response time, but i somewhat
expect the DPL may be able to respond more promptly in cases of
emergency, even if only to coordinate things a little better.

In this specific case, it seems like there is a pending issue that's
been unresolved for way too long. People have explicitly sought
resolution and didn't get it.

What would be your proposed process then?

> Furthermore, putting people and teams together in real life is also
> another unexplored avenue. Whilst this speaks somewhat to my previous
> commitments for more meetups, the angle I am taking here is not waiting
> for the next {Mini,}DebConf or team summit but rather putting the two
> parties in the same room specifically to solve a social problem.

This doesn't strike me as such a good idea in the more serious cases, at
least. Putting victims in front of their opprossors can put a tremendous
emotional load on the victim and cause another traumatic event to
occur... I would be very careful with this approach.

Thanks for your response...

A.

-- 
Omnis enim ex infirmitate feritas est.
All cruelty springs from weakness.
 - Lucius Annaeus Seneca (58 AD)

Re: Q to both candidates: preventing burnout by other contributors

[Ian Jackson]

Russ Allbery writes ("Re: Q to both candidates: preventing burnout by other 
contributors"):
> [analysis of structural problem with toxic behaviours]

I agree entirely with your analysis.

> In Debian, we have very few tools short of outright explusion from the
> project, which obviously everyone is very reluctant to use, and everyone
> knows that.

There are areas and situations where there *are* such tools.

For example, any non-maintainer contributor needs to stay in the good
graces of the maintainer(s).  Any non-DM/DD contributor needs to stay
in the good graces of their sponsor(s).  An RC bug squasher needs the
active positive approval of the Release Team.  Everyone in the
Reproducible Builds team needs to maintain a good personal reputation
and help maintain a good team reputation, so that maintainers across
the project accept their patches.[3]

It's notable that while obviously there are many harebrained and/or
toxic people who might like to try to "contribute" to Debian, we don't
usually experience them as a big problem[1] because our existing power
structures largely work to defend our community.[2]

Core teams are accountable to the DPL, who has a much wider range of
practical options short of firing a team or an individual.  (Whether
this is effective depends on how effective the DPL is as a manager,
and different DPLs' have had different levels of skills.)

Establishment and acceptance of that formal accountability has, I
think, helped the project solve some problems we had.  Our core teams
are mostly working fairly well.

OTOH the problems we have heard described with Debconf show that the
DPL cannot be relied on to act effectively, because they may lack the
necessary management skills.


The big problem is DD/DM maintainers, including team members.  We have
few useful tools between informal public opprobrium (which is a
terrible tool because it's unjust and creates a toxic discussion
environment) and firing someone from maintainership.

Formal peformance management systems in hierarchical organisations
often have an escalating system of advice/warning/reprimand.

I think it would be possible, without radical change to maintainers'
position authority, to institute an escalating system of private and
public advice/warning/reprimand.

But we lack authoritative institutions that are willing and able to
issue such statements.

Part of the problem is our culture of doing everything in public.
Discussions about issuing a team member with formal advice must not be
held in public.  Where teams are involved, the team members lack a
suitable venue for the conversation.

Another problem is that no-one has a template process to follow.  The
DPL could help here by defining a process and setting a good example.

The DPL as a post clearly has the moral authority to issue formal
advice/warnings/reprimands.  But the institution of the DPL lacks the
capacity to use this tool in an effective way.

The TC hates to focus on behavioural problems, and does not like to
use its power to depose maintainers.


I guess what I'm saying is that maybe the DPL should indeed consider
creating an "oversight and mediation committee" who would deal mostly
in private, and would engage in both mediation and disciplinary
communications.

Ultimately that committee might even "recommend to the TC that
so-and-so be removed/replaced as maintainer".


Thanks for your penetrating analysis, anyway.

Ian.


[1] I'm excluding here the problem of harassment by outsiders, which
is very real, but a rather different issue with different causes.

[2] An exception is outsiders engaging in vigorous advocacy campaigns
in debian-devel.

[3] Someone maintaining a minority menu system needs to maintain a
good relationship with the maintainers of desktop packages - and if a
significant minority of desktop package maintainers decide that the
minority menu should be killed (for whatever reason) then the
project's power structure will act as executioner.

Re: Q to both candidates: preventing burnout by other contributors

[Mehdi Dogguy]

On 29/03/2017 20:19, Chris Lamb wrote:
> Furthermore, putting people and teams together in real life is also
> another unexplored avenue. Whilst this speaks somewhat to my previous
> commitments for more meetups, the angle I am taking here is not waiting
> for the next {Mini,}DebConf or team summit but rather putting the two
> parties in the same room specifically to solve a social problem.

I was also thinking this was a good idea. Unfortunately, some situations
do not permit to put the two parties in the same room, which makes things
more complicated to handle. In such cases, one can try to mediate but it
requires significant efforts, time, real mediation skills and careful
wording. You can try to be very careful, and fail because your thought
was not described using the right words. It becomes even more complicated
when the victim in front of you is not able to accept any kind of small
error because in their perception, it might mean compromising with the
offender.

Dealing with such cases is really difficult. Even managers can have a
hard time with some employees because some offenders just do not care
about formal reprimands or having no raise. This is a question the humanity
did not resolve yet and we are not all competent in this area (especially for
persons coming from the IT world where we find it easier to interact with
computers... and even talk with our friends through computers and on
messaging systems where we do not even see their facial expressions).

I am really genuinely proud and really impressed with people behind Debian
Account Managers and Anti-Harassment team. They have been able to deal
with difficult situations and find the right words everytime. I can only
send them *hugs* for dealing with all that and show them the support they
deserve. I think we are really lucky in Debian to have those people. Not
all projects (or even companies!) have the same.

-- 
Mehdi

Re: Q to both candidates: preventing burnout by other contributors

[Enrico Zini]

On Wed, Mar 29, 2017 at 07:19:31PM +0100, Chris Lamb wrote:

> However, I still think that by continually and reliably calling it out
> in general, even in cases where it is unlikely to worsen, means that
> our culture will — in time — change for the better.

I've seen calling out mentioned a number of times. Sometimes I feel like
the escalation involved in calling out makes sense, and sometimes I
feel like an escalation would be unnecessary or unwarranted. For those
times, I am fascinated by the idea of "calling people in":

https://www.theodysseyonline.com/calling-in-verses-calling-out
http://everydayfeminism.com/2015/01/guide-to-calling-in/
https://ofcourseitsaboutyou.com/2014/01/23/calling-out-vs-calling-in-how-activist-techniques-can-be-used-to-decrease-lateral-violence-and-bullying-in-nursing/


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Q to both candidates: preventing burnout by other contributors

[Chris Lamb]

Hi Russ,

In general I would say I agree with your analysis. You raise some
excellent points, especially that the extreme outliers are paradoxically
an quote-easier-unquote case to deal with via expulsion, whilst
behaviours that do not reach that level cause more damage in the
long-term as they are simply around for longer.

(I'll assume for the rest of this thread we are talking about this
sub-exclusion case.)

> 20% or so *won't* when they know perfectly well that they face no real
> consequences from ignoring it provided that they don't *really* mess up.

There's probably a Dunning–Kruger effect [0] factor too, where this
hypothetical 20% may not even realise they are the cause of the
problem, blaming others and/or thinking they are misunderstood…

> we flounder around, talking about providing feedback and calling things
> out but never addressing the fact that there are zero consequences for
> someone simply ignoring all of that feedback.

Indeed. We can't always use social opprobrium as a tool — even being
explicit regarding poor behaviour ("calling it out") doesn't affect, say,
the technical ability to push to a shared Git repo and removing such
rights is a huge step.

> 2. Do you have any thoughts or plans around how to more proactively
>address social problems that fall short of explusion

If I claimed I had a foolproof solution to this problem I would either
be a liar or the saviour of the free software movement in general…

(I'm also somewhat hesitant to give my ideas without some kind of caveat
that its remains unclear to me whether it should be the role of the DPL
to *rule* or even have any input whatsoever on such cases.)

However, I still think that by continually and reliably calling it out
in general, even in cases where it is unlikely to worsen, means that
our culture will — in time — change for the better.

For specific cases, we could look into a "traffic light" warning systems
but moreover make the process of escalation to some kind of third-party 
mediator more frictionless.

Furthermore, putting people and teams together in real life is also
another unexplored avenue. Whilst this speaks somewhat to my previous
commitments for more meetups, the angle I am taking here is not waiting
for the next {Mini,}DebConf or team summit but rather putting the two
parties in the same room specifically to solve a social problem.

  [0] https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Q to both candidates: preventing burnout by other contributors

[Martín Ferrari]

On 29/03/17 17:33, Russ Allbery wrote:

> I think one of the things that makes this very difficult in a project like
> Debian is that there's very little teeth to the constructive feedback,
> which changes the context and emotional tenor of the feedback
> considerably.

THIS. Thanks Russ, I agree 100% with you.

-- 
Martín Ferrari (Tincho)

Re: Q to both candidates: preventing burnout by other contributors

[Jonas Smedegaard]

Quoting Russ Allbery (2017-03-29 18:33:59)
> In Debian, we have very few tools short of outright explusion from the 
> project, which obviously everyone is very reluctant to use, and 
> everyone knows that.

Thankfully we have not yet expluded anyone.

Sorry, couldn't resist.

Thanks for the your intelligent input, Russ - as always!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Q to both candidates: preventing burnout by other contributors

[Russ Allbery]

Chris Lamb  writes:

> In practical terms, we should be pointing out poor behaviour when we see
> it and not relying on the aggrieved party to do so. We could advertise
> more general themes or even slogans along the lines of "If You See
> Something, Say Something" (!) in order to tilt the zeitgeist.

> We could also better help people provide out-of-band (or even private)
> feedback to offenders, letting them know how their behaviour is being
> interpreted by the others and community at large. For example, in such
> messages, it is more productive to concentrate on perception rather than
> focusing on the actions themselves

> Over time, attitudes, tolerances and people can change, but it will
> always be difficult to improve our culture of constructive feedback in
> such a diverse community overnight. I'd love to be able to work with you
> further on this.

Questions at the bottom, but they require a bit of framing, so I'm going
to be long-winded.  Apologies for that!

I think one of the things that makes this very difficult in a project like
Debian is that there's very little teeth to the constructive feedback,
which changes the context and emotional tenor of the feedback
considerably.

In a well-functioning workplace environment, managers raise these sorts of
issues with employees who are hurting the general work atmosphere long
before they rise to the level of requiring dismissal, and with a goal of
never letting them reach that point.  But there is an explicit power
structure in place, and managers have a whole host of tools that they can
use to bring increasing amounts of pressure on an employee who is
poisoning the work environment: they can be reassigned, given
less-enjoyable work, lose privileges, receive a smaller (or no) raise,
receive formal reprimands, etc.  Often none of that is necessary, but
that's partly *because* there's a clear understanding between the employee
and the manager that these sorts of actions *could* be the next step if
the employee just blows off the concern completely.

In Debian, we have very few tools short of outright explusion from the
project, which obviously everyone is very reluctant to use, and everyone
knows that.  Constructive feedback is great, and 80% of people will
respond to constructive feedback and sincerely try to do better.  But 20%
or so *won't* when they know perfectly well that they face no real
consequences from ignoring it provided that they don't *really* mess up.
So if they feel stubborn, or aggrieved, or don't think the feedback is
fair for whatever reason, it's much more comfortable to simply ignore it
than it would be in a workplace.

I think this is at the heart of our problem policing social issues.  We
can get rid of the truly toxic and dangerous via explusion, and we can
encourage each other to do better when everyone involved sincerely wants
to improve the social interaction.  But if there are social conflicts that
don't rise to the level of explusion but are still long-term unacceptable,
we flounder around, talking about providing feedback and calling things
out but never addressing the fact that there are zero consequences for
someone simply ignoring all of that feedback.

Questions to both candidates:

1. Do you agree with the above analysis, or do you see a different
   dynamic?

2. Do you have any thoughts or plans around how to more proactively
   address social problems that fall short of explusion but that will
   require some teeth and actual consequences to get at least one of the
   parties to be willing to change their behavior?

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

Re: Q to both candidates: preventing burnout by other contributors

[Chris Lamb]

Dear Martín,

> Yesterday I posted[0] about my experience dealing with toxic
> contributors in Debian

Thank you so much for sharing this. I hope others will reply to your
post on such an important topic. There are clearly no easy solutions
and regrettably this issue extends far beyond Debian to almost all
free software projects. :(

Now, I do share some of your pessimism regarding inactivity and lack
of acknowledgement but in the last six months I believe the topic of
toxic developers from a mental health standpoint is at least starting
to get the airing it has always deserved.

To underline a few points, you are absolutely right to point out that
a fellow contributor doesn't even have to reach anywhere close the
label of "toxic" or for them to be breaking explicit rules for them
to affect others in a profoundly negatively way.

For example, knowing that I might have a tolerable-but-poor interaction
with a developer could put me off spending more time than I might
otherwise have done. Furthermore, prospective developers observing
from the outside are likely to just pass that team by, calculating it
is not worth the emotional investment.

If the developer believes that their next step is to invoke the CTTE or
DAM, but the interaction doesn't warrant that level just yet, this causes
feelings of disempowerment and even resentfulness towards the project
as a while. This is obviously a detriment to that person's sense of self-
respect and self-worth, but — as a secondary concern — for Debian itself.

I am "lucky" enough that I have not experienced this to the same level 
as you so cannot speak from personal experience (or I may have
subconsciously moved onto other interests). However, on consulting
others over the past few days, one common theme/idea is that to tolerate
is — essentially — to approve of it.

In practical terms, we should be pointing out poor behaviour when we see
it and not relying on the aggrieved party to do so. We could advertise
more general themes or even slogans along the lines of "If You See
Something, Say Something" (!) in order to tilt the zeitgeist.

We could also better help people provide out-of-band (or even private)
feedback to offenders, letting them know how their behaviour is being
interpreted by the others and community at large. For example, in such
messages, it is more productive to concentrate on perception rather than
focusing on the actions themselves

Over time, attitudes, tolerances and people can change, but it will always
be difficult to improve our culture of constructive feedback in such a
diverse community overnight. I'd love to be able to work with you further
on this.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-