[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.


Reply to: