Re: Learning from FreeBSD's mistakes

[Don Armstrong]

On Tue, 28 Mar 2017, Martín Ferrari wrote:
> If somebody repeatedly is:
> 
> * performing a substandard job that affects you directly or indirectly,
> * ignoring team practices, or flat-out moving packages out of the team
> to avoid team policies,
> * performing uncoordinated uploads that break reverse dependencies,
> * deciding that they don't like your git packaging style and overwriting it,
> * when criticised argue that they don't have time for your complaints
> because they do so much packaging work, etc.
> 
> What do you do?

Talk with them. If possible, meet face to face (schedule a sprint?)
Maybe involve a neutral third party who is respected by both members to
help mediate.

Accept that sometimes people are going to have different metrics of what
a "good job" is. Avoid calling their work "substandard", as that's a
value judgement, and makes the disagreement adversarial.

> This is much worse if said person and their packages are not in a
> team. Then your only recourse is CTTE. We don't have social solutions
> for these social problems.

I think we're selling ourselves short; we have all of the social
solutions,[1] but they're time consuming and hard to enact.

1: From internal communication, to mediation, to CTTE deciding
maintenance, to expulsion.

-- 
Don Armstrong  https://www.donarmstrong.com

[A] theory is falsifiable [(and therefore scientific) only] if the
class of its potential falsifiers is not empty.
 -- Sir Karl Popper _The Logic of Scientific Discovery_ §21

Re: Learning from FreeBSD's mistakes

[Martín Ferrari]

On 06/02/17 11:18, Ian Jackson wrote:

> I hope we do much better than FreeBSD in our response to harassment.

I have been meaning to write about this for a long time, then I was
going to join this discussion and postponed it. But now thinking about
the DPL candidates' platforms, I came back to this topic.

I think we are much better than what we used to be. Maybe we are doing
better than FreeBSD. But we are deluding ourselves if we think that
Debian is always a fun or welcoming place to be.

There are many ways in which project contributors can make you feel
miserable without violating any of our written rules. And we are very
ill equipped to deal with that. We lack mechanisms to tell somebody that
their behaviour is harmful, much less to force them to stop.

There are social *and* technical issues that can degrade your experience
as a Debian contributor to the point of draining all you energy and
motivation away. And I don't see that we are making any progress on this.

On the technical side, we have people doing mediocre to terrible jobs.
In an ideal world, they will learn and correct their ways when their
peers give thembad feedback, but others will just ignore the community
around them.
We have some safeguards against this, but DDs are mostly free to do
whatever, except when going through NEW. This affects the distribution
as a whole, but more importantly, affects other people trying to do a
good job.

This becomes much worse if you are forced to interact with them, because
there are mutual dependencies, or your packages are highly connected in
some way. Then social problems get added to the technical ones.
Packaging teams can be great, but are also where people with abusive
behaviours do the most damage.

Personally, I have many times considered resigning from a packaging team
because of one member behaving like an arsehole. In the end, I managed
to stay put and keep working, because I was really motivated by my packages.

But how many other people just quit for their own sanity? What message
are we giving to the newcomers when they see that these attitudes are
not stopped?


If somebody repeatedly is:

* performing a substandard job that affects you directly or indirectly,
* ignoring team practices, or flat-out moving packages out of the team
to avoid team policies,
* performing uncoordinated uploads that break reverse dependencies,
* deciding that they don't like your git packaging style and overwriting it,
* when criticised argue that they don't have time for your complaints
because they do so much packaging work, etc.

What do you do? None of these are enough to invoke DAM or the harassment
team. You could expel them from the team, but then you need to take
extra technical steps to avoid further damage which will also affect
your team in other ways, and the costs become too high.

This is much worse if said person and their packages are not in a team.
Then your only recourse is CTTE. We don't have social solutions for
these social problems.

This is but only one example, I have heard other first hand accounts of
similar situations. We are not doing much to fix this, or even
acknowledge it, and I think we should.


-- 
Martín Ferrari (Tincho)



signature.asc
Description: OpenPGP digital signature

Re: Learning from FreeBSD's mistakes [and 1 more messages]

[Don Armstrong]

On Mon, 06 Feb 2017, Ian Jackson wrote:
> This distributed approach has strengths (which Don points out) but it
> also has weaknesses. Principally, it means that though we advertise a
> single point of contact, that point of contact is mostly a go-between
> and support function for forum-specific teams;

The antiharassment team is the single publicly-advertised point of
contact, and (in theory) knows which teams are responsible for all of
the different communications channels and events. Many forums also
advertise a forum-specific point of contact which can take action more
rapidly.

> and it also makes it somewhat harder for us to respond to problems
> with span several communication channels or several events.

The few cases where we have had an individual which has been harassing
others which spanned multiple forums, at least listmaster@ and owner@
have been able to communicate fairly effectively and implement
consequences fairly rapidly.

Even if antiharassment@ was given the authority to establish
consequences directly, it would still require action of the teams in
question to enact those consequences.

-- 
Don Armstrong  https://www.donarmstrong.com

Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_

Re: Learning from FreeBSD's mistakes [and 1 more messages]

[Ian Jackson]

Don Armstrong writes ("Re: Learning from FreeBSD's mistakes"):
> On Mon, 06 Feb 2017, Ian Jackson wrote:
> > Paul Wise writes ("Re: Learning from FreeBSD's mistakes"):
> > > https://wiki.debian.org/AntiHarassment
> > 
> > I'm aware of this team.
> > 
> > But they do not have any authority to take steps against harassers.
...
> Indeed, in at least the case of lists, IRC, and the BTS, action tends to
> get taken well before the antiharassment team is contacted and/or
> involved.

Yes.  This is good.

> > What this means is that the antiharassment team cannot even issue a
> > proper warning against a harasser. (A proper warning being one where
> > consequences clearly follow if the warning is not heeded.)
> 
> I think the antiharassment team should involve the appropriate team
> (organizer, owner@, listmaster@, DAM, etc.) in the drafting of a warning
> so that the appropriate consequences can be taken.
> 
> The specific teams of a medium are the appropriate teams because they
> have the technical experience and community involvement necessary to
> enact consequences. [For example, the organizers of an event will know
> the appropriate means of excluding someone from an event, or even if
> that is possible.[1]]

These are all good points.

> Personally, I am very happy to work with the members of the
> antiharassment team to make sure that any warning that needs to be
> issued has appropriate consequences for any of the parts of Debian whose
> governance I participate in.

Excellent.

However, this subthread is about my assertion that:

   In Debian there is no single team responsible for responding to
   harassment problems.

(which was part of a contrast with FreeBSD).

Paul Wise pointed out the antiharassment team.  But as the thread
shows, the antiharassment team is not Debian's "single team
responsible for responding to harassment problems".

This distributed approach has strengths (which Don points out) but it
also has weaknesses.  Principally, it means that though we advertise a
single point of contact, that point of contact is mostly a go-between
and support function for forum-specific teams; and it also makes it
somewhat harder for us to respond to problems with span several
communication channels or several events.

Sorry if my mails seemed too critical.

Ian.

Re: Learning from FreeBSD's mistakes

[Milan Kupcevic]

On 02/06/2017 08:13 AM, Ian Jackson wrote:
> Paul Wise writes ("Re: Learning from FreeBSD's mistakes"):
>> On Mon, Feb 6, 2017 at 7:18 PM, Ian Jackson wrote:
>>>> In Debian there is no single team responsible for responding to
>>> harassment problems
>>
>> There is a team for that:
>>
>> https://wiki.debian.org/AntiHarassment
> 
> I'm aware of this team.
> 
> But they do not have any authority to take steps against harassers.
> 


Their authority comes from particular merits of their activity. They can
coordinate, investigate, advise, warn, inform and finally recommend
measures to the appropriate executive bodies and community at large. Is
this good enough?

M



signature.asc
Description: OpenPGP digital signature

Re: Learning from FreeBSD's mistakes

[Don Armstrong]

On Mon, 06 Feb 2017, Ian Jackson wrote:
> Paul Wise writes ("Re: Learning from FreeBSD's mistakes"):
> > https://wiki.debian.org/AntiHarassment
> 
> I'm aware of this team.
> 
> But they do not have any authority to take steps against harassers.

They don't have the authority to take steps unilaterally, but I'm not
aware of a case where harassment has occurred and the appropriate team
has not taken action upon recommendation by the antiharassment team.

Indeed, in at least the case of lists, IRC, and the BTS, action tends to
get taken well before the antiharassment team is contacted and/or
involved.

> What this means is that the antiharassment team cannot even issue a
> proper warning against a harasser. (A proper warning being one where
> consequences clearly follow if the warning is not heeded.)

I think the antiharassment team should involve the appropriate team
(organizer, owner@, listmaster@, DAM, etc.) in the drafting of a warning
so that the appropriate consequences can be taken.

The specific teams of a medium are the appropriate teams because they
have the technical experience and community involvement necessary to
enact consequences. [For example, the organizers of an event will know
the appropriate means of excluding someone from an event, or even if
that is possible.[1]]

Personally, I am very happy to work with the members of the
antiharassment team to make sure that any warning that needs to be
issued has appropriate consequences for any of the parts of Debian whose
governance I participate in.

1: For example, some venues may not allow prior restraint or have other
specific legal requirements which must be met to legally exclude
someone.
-- 
Don Armstrong  https://www.donarmstrong.com

Miracles had become relative common-places since the advent of
entheogens; it now took very unusual circumstances to attract public
attention to sightings of supernatural entities. The latest miracle
had raised the ante on the supernatural: the Virgin Mary had
manifested herself to two children, a dog, and a Public Telepresence
Point.
 -- Bruce Sterling, _Holy Fire_ p228

Re: Learning from FreeBSD's mistakes

[Ian Jackson]

Paul Wise writes ("Re: Learning from FreeBSD's mistakes"):
> On Mon, Feb 6, 2017 at 7:18 PM, Ian Jackson wrote:
> > > In Debian there is no single team responsible for responding to
> > harassment problems
> 
> There is a team for that:
> 
> https://wiki.debian.org/AntiHarassment

I'm aware of this team.

But they do not have any authority to take steps against harassers.

AIUI they are not able to ban anyone from our IRC channels or from the
BTS or our mailing lists; they are not able to revoke DM or DD status;
they are not able to revoke maintainer status; and they have no
authority to exclude anyone from a Debian-related event.

Instead, those decisions are taken by, respectively: IRC channel
operators; BTS and list admins; DAM; sponsors and/or the TC; and the
organisers of each specific event.

What this means is that the antiharassment team cannot even issue a
proper warning against a harasser.  (A proper warning being one where
consequences clearly follow if the warning is not heeded.)

Ian.

Re: Learning from FreeBSD's mistakes

[Paul Wise]

On Mon, Feb 6, 2017 at 7:18 PM, Ian Jackson wrote:

> In Debian there is no single team responsible for responding to harassment 
> problems

There is a team for that:

https://wiki.debian.org/AntiHarassment

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Learning from FreeBSD's mistakes

[Ian Jackson]

I was recently pointed to this article about some of the problems
facing the FreeBSD community:
https://lwn.net/Articles/712308/

I found it interesting.

There are very significant parallels between FreeBSD and Debian.

We are both very old projects.  We are both large.  Both Debian and
FreeBSD are (in their own ways) deeply conservative institutions.

In both projects, the group with principal formal responsibility for
resolving technical disputes (FreeBSD core and the Debian TC) always
wants to act with consensus and responds only very slowly.

I hope we do much better than FreeBSD in our response to harassment.
In Debian the response to such problems is separate from technical
decisionmaking, which is good.  In Debian there is no single team
responsible for responding to harassment problems, and the skills and
resources of the different teams and different people vary.

I think we have *mostly* got over the idea that we should highly value
a developer who makes big technical contributions in key areas, but
whose relationships with others are poor.  (I do like the way the
article reframes "rockstar" as someone with too big an ego...)

A key difference is that Debian development is much more fragmented
(or compartmentalised, if you will).  This means that much of the time
one does not need to deal with Debian as a whole - only with *much*
smaller subprojects.  Most of those subprojects work well.  But if
they don't, you can't fork them (which is what you might do with a
broken project otherwise), so you're back to dealing with the
project-wide institutions.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.